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PREFACE 


1.0 Manual Objectives 


The BASEWAY Softwar^ Installation Quide/Release Notes 
manual shows how to install BASEWAY on VAX/VMS and provides 
dditional information about defining an application and 
ailoring the product for specific user applications. 


2. 0 Audience 


This manual is intended for those individuals who must 
set up and maintain the VAX/VMS operating sgstem and BASEWAY 
software. 


3. 0 Prerequisites 


Readers of this manual should have a solid understanding 
VAX/VMS operations and administration# and VAX application 
jftware. In addition# a knowledge of the specific 
requirements of the installation site is essential. 


4.0 Structure of This Document 


This manual is organized as follows: 

Chapter 1: Gives an overview of the BASEWAY system. 

Chapter 2: Describes the* BASEWAY distribution kit# 

installation prerequisites# and the actual installation 
procedure. 

Chapter 3: Describes the steps involved in defining an 
application on BASEWAY. 


Chapter 4: Contains Release Notes which you should read 
before installing BASEWAY. This chapter includes information 
not included elsewhere in the documentation set# changes made 
late in the development cycle# software errors# and 
documentation omissions. 
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Appendix A: Shows a sample installation procedure. 

5.0 Associated Documents 

Further information on various topics covered in this 
manual may be found in the following manuals: 

o PgCnet VMS System Manager ^s * Guide 

<order number AA-H803B-TE). 

0 SHOP FLOOR GATEWAY Installation Guide/Release Notes 

(order number XX-12355—01) 

0 BASEWAY System Programmer '9 Guide 

(order number XX-12346-01) 

0 BASEWAY User 's Manual and Utilities Guide 

(order number XX—12347-01) 

0 PROGRAMMABLE DEVICE SUPPORT 
Guide/Release Notes 

(order number i2365-XX) 

0 VAX ALL-IN-1 Installation Guide/Release Notes 
0 VAX DATATRIEVE Installation Guide/Release Notes 
o VAX FMS Installation Guide and Release Notes 
(order number AA-L221A-TE) 

0 VAX FMS Uti1ities Referenoe Manual 
(order number AA-L320A-TE) 
o VAX PL/I InstalTation Guide 
(order number AA-J179A-TE) 
o VAX 5oftware Installation Guide 
(order number AA-M545A-TE) 
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o VAX/VMS Command Lanfluaoe User Guide 
(order number AA-D023B—TE) 
o VAX/VMS Sustem Manager *s Quide 
(order number AA-M547A-TE) 


6.0 Disposition of Software Performance Reports (SPRs) 


Questions/ problems/ and enhancements to Digital software 
should be reported on a Software Performance Report (SPR) form 
and mailed to the appropriate Digital office. Onli| one 
problem should be described concisely on each SPR form. 
Please include all programs and data in machine^readable form 
and reference the SPR form number on the materials. 







CHAPTER 1 


OVERVIEW OF BASEWAY 


1. 1 What Is BASEWAY? 


BASEWAY is a tool to dafino/ monitor/ and control programmable 
devices and support various user applications. It can work together 
with Digital's SHOP FLOOR GATEWAY product which provides the actual 
communications interface to shop floor devices. Up to four gateways 
per system are permitted. The gateways are PDP—ll/24s. or PDP-ll/44s 
(run memory-only RSX-llS operating system). 
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Figura 1. Sample VAX-To-FDP Sgstem Configurations 
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1.2 Hardware Requirements 

¥' ' ■ 

— VAX 11/750 or 11/780 (memory size dependent upon application) 

- PDP-11/24 (or PDP-11/44) 512KB minimum 

- Hardware to support DECnet links between the VAX and PDP 

- 11/24/ including the automatic boot module for the 11/24. 

- Console terminal 

1.3 Software Requirements 

- VAX DECneti Version 3. 0 

- VAX FHS/ Version 2. 1 

' - VAX/VMS/ Version 3. 5 

No database for user data or applications . other than that 
necessary to define the network is provided. 

In addition/ VAX PL/1* Version 2.0/ is required if any additional 
programmable device types are to be added during tailoring. 

1. 3. 1 Optional Software 

The following are optional software products/ but are suggested 
for program development; 

+ VAX CDD> Version 2.2 


+ VAX DATATRIEVE/ Version 2. 1 
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VAX 

DBMS 

+ 

VAX 

TDMS# Version 1.0 


VAX 

ACMS# Version 1. 0 


VAX 

ALL-IN-1# Version 1. 1 


1.4 DATATRIEVE Acctss 


If DATATRIEVE is installodf DATATRIEVE dsfinitions may be added 
or altered for BASEWAY tailoring. During installation^ domain and 
record definitions are placed in the CDD^TOP. BSL'$LIB dictionary. 
These definitions may be used as desired. 

If VAX DATATRIEVE is installed on the target system# the BASEWAY 
installation procedure uiill place domain and record definitions for 
each of the BASEWAY database files in the CDD4TQP. BSLi^LIB dictionary. 
These may be used as necessary to create custom reports of the BASEWAY 
definitions. However# the format and contents of each of these 
database files are subject to ciiange in future versions of BASEWAY. 
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CHAPTER 2 


INSTALLING THE SOFTWARE 


The system manager should be familiar with the installation 
process as described herein for use in installing upgrades and 
updates. 

Depending on the mass storage device and the system load^ the 
installation of BASEWAY may take from 15 to 30 minutes. 


2. 1 Backing Up the System Disk Before Software Installation 

' It is recommended that the system disk be backed up prior to 


stallation. The procedure for 
.HtX Software Installation Guide . 


2. 2 Contents of the Distribution 


The BASEWAY installation kit 
All files required to install 
contained on the distribution. 

Each volume is labeled w 
corresponding to BASEWAY's produc 

Volume Label Medium 


doing the backup is described in the 

Kit 

is distributed on magnetic tape, 
and tailor the BASEWAY system are 

th an external serial number 
number and a unique volume label. 

Contents 


BSLOlO 


1600 bpi 
magnetic tape 


BASEWAY installation 
command procedures and 
software 
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NOTE; Be sure to check that the distribution kit you receive 
contains everything listed in the bill of materials enclosed uiith it. 
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2. 3 Installation Procedure 
2.3. 1 Preliminary Requirements 

NOTE: BASEUAY requires VAX/VMS Version 3. 5 or later. 

o approximately 9000 blocks (BASEWAY peak usage) during 

installation 

o approximately 8000 blocks (BASEWAY net usage) after 

insta nation 

0 previous installation of DECnet (v. 3. 0) and FMS (v. 2. 1). 


2.3.2 Instructions for Installation 


Messages are printed at your terminal during the installation 
procedure. Most are simple "Yes” or "No" questions which require 
either a Y or N response. 

Proceed as follows at the console terminal (user input is shown 
'H uppercase letters): 


2. 3.2. 1 STEF 1: t-og In to the System Manager Cs Account - 

1. Log in under a privileged system manager's account.* as shown 
in the following example: 


cr 

Username: SYSTEM cr 

Password: ,cr 


Now set up the proper group and user number and set the 
default directory to SYSUPD as follows: 

« SET UIC Cli43 
4 SET DEFAULT SYS^UPDATE 
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2. 3. 2. 2 STEP 2: Invoks V^fSINSTAL - 

Whsn gou invok® VMSINSTALi it chscks the following: 

0 Art gou loggtd in to tht sgsttm manager's account? 

It is recommended that gou install lagered software from 
the sgstem manager's account. However^ ang account with the 
necessarg privileges is acceptable. 

0 Do gou have adequate account quotas for installing lagered 
products? 

As long as the quotas listed in- Section 2. 3. 1 are met/ 
gou can continue with the installation. 

o Is DECnet up and running? 

You should stop DECnet before installing BASB4AY. 
Although the installation will succeed/ problems can occur if 
someone tries to access ang file associated with BASEWAY 
(including the sgstem HELP files) during the installation. 

o Are ang users logged in to the sgstem? 

Users should be asked to log out before BASEWAY is 
installed. Although the installation mag succeed/ problems 
can occur if someone tries to use BASEWAY while the 
installation is in progress. 

If any of these conditions are noted/ VMSINSTAL will give you an 
opportunity to stop the installation procedure (see below). 

To invoke VMSINSTAL/ enter the following: 

< aVMSINSTAL BSLnnn ddn: 


The VMSINSTAL command procedure takes two parameters: 

1. product name-’^for BASEWAY the name always begins with “BSL" 
and ends with a 3-digit version number. For example/ Version 
1.6 would be denoted as BSL016. Hereinafter/ this document 
will refer to the version number as Vn.n. 

2. device name—device names have the form ddn:/ where dd is the 
device code and n is the unit number. For example/ the first 
floppy diskette drive would be called "DYO:”. 
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NOTE; It is not necessary to use the console drive for 
installing BASEWAY. Houieverj if you do use it^ be sure to 
replace any media you may have .found in the drive when the 
installation is complete. 

VAX/VMS Software Product Installation Procedure 

It is dd~mmffl—19yy at hh:mm 

Enter a question mark (?) at any time for help 

* Are you satisfied with the backup of your system disk CYES3? 


If you feel that there are conditions which may adversely affect 
the installation» enter N and the installation will stop. If you wish 
to continue/ enter Y (or press RETURN). 


2. 3. 2. 3 STEP 3: Insert the First Installation Kit Volume - 
Please mount the first volume of the set on ddn; . 


Insert the first volume of the distribution kit and type "Y" when 
you are ready to continue. 

* Are you ready? Y 


The BASEWAY installation procedure now assumes control. The 
procedure checks to see that there is adequate disk space to build the 
product. If not/ it issues an error message and terminates. 
Otherwise/ the procedure processes the first volume of the backup save 
set. 

NOTE: If the SYSGEN parameters MOUNTMSC or DISMOUNSG at your 
site have been set to 1/ you will receive a message from OPCOii each 
time a disk/ tape/ or floppy diskette is mounted or dismounted. These 
messages are normally disabled/ but if they have been activated and 
you are installing from a console terminal/ they will appear from 1 to 
30 seconds after each mount or dismount. 

XMOUNT-I-MOUNTED/ BSLnnn mounted on ddn: 

. The following products will be installed: 

BSL Vn. n 

Beginning installation of BSL Vn.n at hh:mm 
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%VMSINSTAL-I-RESTOREi Restoring product savssat A. . . 

Prsvious logical namo assignmant replacad 

At this pointi if you need to exit from the installation 
procedurai you must press CTRL/Y. 

NOTE: If you press CTRL/Y# the installation procedure deletes 

all files it has created up to that point and exits. 

BSLSTART. COM# the startup coiiuaand procedure# is used to set up the 
environment for the BASEMY Application Bus. During installation# 
it will be placed in the CSYSMGRI directory of the system root on 
which this installation is being performed. SYS^MANAGER:SYSTARTUP. COM 
your system startup procedure# should be modified to invoke this 
procedure when the system boots. However# it will not be necessary 
to reboot the system after the installation# since this procedure 
is invoked as part of the Installation. 

%VMSINSTAL-I-MOVEFILES# Files will now be moved to their target 
directories. . . 


Next# an Installation Verification Procedure (IVP) runs- tests to 
check that the installation procedure was successful. 

Installation Verification Procedure (IVP> starting 

The, installation verification of BASEWAY Application Bus vn. n 
successful. 


Successful installation of BSL Vn. n at hhimm 


BASEWAY images and libraries are now successfully installed. You 
may now install more products# or you can end the installation 
procedure. To end the installation procedure# type ”EXIT” (or press 
RETURN). 

Enter the products to be installed from the next distribution 
volume set. 

♦ Products CEXITl: EXIT 

VMSINSTAL procedure done at hh:mm 

# 

If you removed any media from the console drive before beginning# 
you can replace it now. 
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WARNING: VMSINSTAL deletas or changes entries in the logical 
me tables during the installation. Therefore/ if gou are going to 
.jntinue using the system manager's account/ you should log out and 
log in again to restore those tables. 


2.3.3 Error Conditions 




If the installation procedure or IVP fail for any reason/ the 
following messages are displayed: 

5CVMSINSTAL-E-BSLFAIL/ The installation of BSL Vn. n has failed. 
%VMSINSTAL-E-IVPFAIL/ The IVP for BSL Vn. n has failed. 

An error during the installation can be caused by one or more of 
the following conditions: 

o insufficient disk space to complete the installation 
0 insufficient system virtual page count parameter 
0 insufficient process paging file quota 
0 insufficient process working set quota 
0 insufficient system maximum working set 
o insufficient, system global pages 


When you are notified that one of these conditions exists/ you 
should take the appropriate action as described in the message. 

To change a system parameter/ or to increase an authorized quota 
value/ you may need to contact your installation system manager. 


2.4 Backup Procedure After Installation 


After installing BA5EWAY you should back up the system disk and 
save the original for future reference. See the VAX Software 
Installation Guide for information on the proper procedure. 
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2. 5 BASEWAY Dirsctorg Structurss 


Ths installation procsdure crsates VAX dirsctory structures on 
the systeni disk. The following shows these structures; 


Root Directory 
ALL-IN—1 menu forms 
Standard menu forms 
Source directories 
Data Processor source files 
Source files necessary for 
adding new prograimaable 
device type 


SYS«SYSRQOT:CBSLl 
SYS«SYSROOT:CBSL. AlMENUl 
SYS«SYSROOT:CBSL. MENUl 
SYS4SYSR0QT:CBSL. SOURCE! 
SYS*SYSROOT:CBSL. SOURCE. DATAPROC3 


SYS«SYSROOT:CBSL. SOURCE. LIBRARY! 


3ASEWAY system images 


SYS^SYSROOT:CBSL. SYSTEM! 



2. 3. 1 Application Directory Structure 


Root directory (user-specified Cxxxxx! 

at creation) 

BASEWAY data files C. DATA! 


(others may 


he created to 


suit 


app1ication 


needs) 



2.6 Systemwide BASEWAY Logical Names 


BSLSAIMENU 

3SLODEVICE FILE 

SSLOENTITY.FILE 

3SLSF0RMS 

eSL^HISTORY.FILE 

3SL«MENU 

BSL^PQLLING FILE 

SSLisREG I STER_F ILE 

BSL^SYSDATA 

BSLOSYSTEM 

3SL«SYSTEM_FILE 

BSLOTERMINAL.FILE 

BSLOUSER_FILE 


SYS^SYSROOT: CBSL. AlMEiNU! 
BSLOSYSDATA;DEVDEF. DAT 
BSL^SYSDATA:ENTDEF. DAT 
SYS^SYSROOT:CBSL. SYSTEM! 
BSLODATA:HISTORY. DAT 
SYS^SYSRGOT: CBSL. MENU! 
BSLOSYSDATA:POLDEF. DAT 
BSL-SSYSDATA: REGDEF. DAT 
SYS^SYSROOT: CBSL. SYSTEM! 
SYS^SYSROOT: CBSL. SYSTEM! 
BSLOSYSDATA; SYSDEF. DAT 
BSLOSYSDATA: TERMDEF. DAT 
BSLOSYSDATA:USERDEF. DAT 
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2. 7 Groupuiidc BASEWAY Logical Name 


"BSL^DATA" is a groupuiide BASEUAY logical name which is created 
by EVENT^PROC when it is initiated. Logical names that are based on 
this (such as BSLt>HISTORY_FIL£) and which are created by the command 
file SYS4MANAGER:BSLSTART. COMi may not be referenced until an 
application is running. 

Other group logical names which are specific to your application 
may be created by editing the EVENT^PROC startup command file. 


2.S Complete List of Installed- Files 


Filename 


Purpose 


SYS^SYSROOT:CSYSMGRJ 

BSLSTART. COM 

SYSSSYSROOT:CSYSLIB3 

BSLDEF. BAS 
BSLDEF. FOR 
BSLDEF. H 
BSLDEF. LIB 
BSLDEF. PAS 
BSLDEF. PLI 
BSLDEF. REQ 
BSLLIB. OLB 
BSLPLI. TLB 
BSLSHR. EXE 
BSLSHRBLD. COM 

3Y3$SYSR00T:CSYSMSG3 

BSLMSG. EXE 
5FGMSG. EXE 


BASEWAY star.tup command file 


VAX BASIC definitions for BASEWAY routines 
VAX FORTRAN definitions for BASEWAY routines 
VAX C definitions for BASEWAY routines 
VAX COBOL definitions for BASEWAY routines 
VAX PASCAL definitions for BASEWAY routines 
VAX PLI definitions for BASEWAY routines 
VAX BLISS-32 definitions for BASEWAY routines 
Object library containing BASEWAY routines 
Text library containing all BASEWAY definitions 
Sharable image containing BASEWAY routines 
Command file to relink BSLSHR.EXE sharable image 


Image file containing BASEWAY messages 

Image file containing SHOP FLOOR GATEWAY messages 


SYS$SYSROOT: CBSL. A1MENU3 


AIMENU. FLB 

Standard 

form librar 

EDTADDR. COM 

Command 

file 

to 

run 

EDTAPPL. COM 

Command 

file 

to 

run 

EDTDEVICE. COM 

Command 

file 

to 

run 

EDTGATE. COM 

-•Command 

file 

to 

run 

EDTSET. COM 

Command 

file 

to 

run 

EDTTERM. COM 

Command 

file 

to 

run 


y for ALL-IN-1 menu support 
EDTADDR image from ALL-IN—1 
EDTAPPL image from ALL-IN—1 
EDTDEVICE image from ALL-IN- 
EDTGATE image from ALL-IN-1 
EDTSET image from ALL-IN-1 
EDTTERM image from ALL-IN-1 


1 
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cDTUSER. COM 
UTLAPPSTS. COM 
UTLDISDEV. COM 
UTLDISPNT. COM 
UTLDISTRM. COM 
UTLDISUSR. COM 
UTLEVTHIS. COM 
UTLQATSTS. COM 
UTLNOTYET. COM 

SYS«SYSRCOT:CBSL. MENU3 
MENU. FLB 


Cammand 

Command 

Command 

Command 

Command 

Command 

Command 

Command 

Command 


fila to 
fila to 
fila to 
file to 
file to 
fila to 
fila to 
fila to 
fila to 


EDTUSER image 
UTLAPPSTS imag 
UTLBISDEV imag 
UTLDISPNT imag 
UTLDISTRM imag 
UTLDISUSR imag 
UTLEVTHIS imag 
UTLCATSTS imag 
UTLNOTYET imag 


from ALL-IN—1 
a from ALL-IN—1 
a from ALL-IN—1 
a from ALL-IN-1 
a from ALL-IN-1 
a from ALL-IN-1 
a from ALL-IN—1 
a from ALL-IN—1 
a from ALL-IN—1 


Standard form library for BASEWAY menu driver 


SYS^SYSROOT: CBSL. SOURCE. DATAPROCl 


DATAPROC. BLD 
DATAPROC. PLI 


Commanrd fila to recompile and link DATAPROC 
Sample polled data sink program 


SYSSSYSROOT: CBSL. SOURCE. LIBRARYl 


BSLMSG. MSG Source 
PARSEADDR. MAR Source 
PDAPCOMP. PLI Source 
PDAPDNLOD. PLI Source 
PDAPERROR. PLI Source 
PDAPGDEF. PLI Source 
PDAPGMFR. PLI Source 
PDAPGMFRL. PLI Source 
PDAPGMOD. PLI Source 
PDAPGMODL. PLI Source 
PDAPGNET. PLI Source 
PDAPNXTAD. PLI Source 
PDAPSTART. PLI Source 
PDAPSTOP. PLI Sourca 
PDAPTMFR. PLI Source 
PDAPTMOD. PLI Source 
PDAPTNET. PLI Source 
PDAPTRAN. PLI Source 
PDAPUPLOD. PLI Source 
SFOMSG. MSG Sourca 

SYSSSYSROOT; CBSL. SYSTEM! 


file for BASEWAY messages 

file for parse address state tables 

file for compile' address routine 

file for download device routine 

file for translate gateway error routine 

file for get device default routine 

file for get manufacturer routine 

file for get manufacturer list routine 

file for get model routine 

file for get model list routine 

file for get network routine 

file for get next address routine 

fils for start device routine 

file for stop device routine 

file for translate manufacturer routine 

file for translate model routine 

file for translate net routine 

file for translate device address routine 

f-ile for upload device routine 

file for SHOP FLOOR GATEWAY messages 


DATAPROC. COM 
DATAPROC. EXE 
DEFUsiE.APP. COM 
DEVDEF. DAT 
EDITOR. FLB 
EDTADDR. EXE 
EDTAPPL. EXE 


Startup file for sample DATAPROC 
Sample polled data sink image 
Define application command file 
Device definition data file 
Form library for BASEWAY editors 
Device address editor image 
Application editor image 


(called by EVENTPRc4 
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EDTAPPMNT. EXE 
EDTDEVICE. EXE 
EDTGATE. EXE 
EDTSET. EXE 
EDTTERM. EXE 
EIlTUSER. EXE 
ENTDEF. DAT 
EVENTLOG. COM 
EVENTLOG. EXE 
EVENTPROC. EXE 
EVTHIS. FDL 
GATEINIT. COM 
GATEINIT. EXE 
LOOPTEST. EXE 
MEW. EXE 
M0DLDC384. EXE 
MODLDCASA. EXE 
M0DLDC584. EXE 
NI. COM 
NI. EXE 
PHYLO. EXE 
PHYLOGMAN. EXE 
POLDEF. DAT 
REGDEF. DAT 
SYSDEF. DAT 
TERMDEF. DAT 
USERDEF. DAT 
UTILITY. FLB 
UTLAPPSTP. EXE 
UTLAPPSTS. EXE 
UTLDISDEV. EXE 
UTLDISPNT.-EXE 
UTLDISTRM. EXE 
UTLDISUSR. EXE 
UTLEVTHIS. EXE 
UTLGATSTB. EXE 
UTLINIVDR. EXE 
UTLNOTYET. EXE 
UTLVDRDMP. EXE 


Application definition utility image 
Device editor image 
Gateway editor image 
Device set editor image 
Terminal editor image 
User editor image 

Point and group definition data file 
Startup file for EVENTLOG (called by EVENTPROC) 

Event Logger image 
Event Processor image 

File Description Language for system audit file 
Startup file for GATEINIT (called by EVENTPROO 
Gateway Initializer image 
Loopback test utility image 
Menu driver image 

Mod icon 184/384 Load/Dump/Compare image 
Modicon 484 Load/Dump/Compare image 
Modi con 584 Load/Dump/Compare image 
Startup file for NI (called by EVENTPROC) 

Network Interface image 
A1len-Bradley PLC-3 physical to logical converter imagt 
Baseway driver image for PHYLO 
Polling set definition data file 
Device register definition data file 
Application^ gateway^ and device set data file 
Terminal definition data file 
User definition data file 
Form library for BASEWAY utilities 
Application shutdown.uti1ity image 
Application status display image 
Device display image 
Point display image 
Terminal display image 
User display image 
System audit display image 
Gateway status display image 
Reinitialize gateway database utility image 
Missing function display image 
Gateway database display utility image 
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CHAPTER 3 


SETTING UP USER APPLICATIONS 


After your BASEWAY system has been installed/ you may define your 
user applications. 

3.1 Defining Applications 

Figure 2 below illustrates some of the steps involved in defining 
applications. The various steps are described in this chapter. 

1 Design and code your application. 


2 Run DEFINEAPP. COM to create 
a user account/ login command file/ 
and application. 


3 Edit STARTUP.COM to include your 
application. 


4 Change MENU to reflect 
your application. 

Figure 2, Defining An Application 
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3. 1. 1 Invoking DEFINEAPP. COM 

To craata an application^ you must invoka tha command file 
DEFINEAPP. COM. This file defines .the parameters needed to get a new 
application running on the system. 

DECnat must be up before you invoka DEFINEAPP and start your 
application. 

For information about defining accounts^ see Section 3. 2. 

The*following is a sample definition of Application Number 
”0003". It is a continuation of the installation dialog which started 
in Section 2. 3. 2. 

CAUTION: Make every effort to type accurately when responding to the 

prompts in this command procedure. 

« SET DEF BSL^SYSTEM 
< «DEF1NEAPP 

BASEWAY Application Configuration Procedure ** 

This procedure will define the parameters needed to get a new 
application running on this system. 

You may respond to any question or prompt with a "?" if help 
is needed. 

* Application name ? FIE1JD_TE5T 

» CONFIRMATION; Is "FIELD-TEST” the correct name ? YES 
Creating application FIELD—TEST. . . 

Application number CC03 created... 

* Group number for application C11-377I ? 100 

* Disk for data directory (if not DRAG:) ? cr 

* Root directory (if not APP0003> ? TESTAPP 

Creating directory DRAO:CTESTAPP3. . . 

Creating directory _^DRAO: C TESTAPP. DATA I. . . 

Creating Database files... 
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Creating BSLSSYSTEM: APP0003. COM. . . 

Creating _ ^DRAO: CTESTAPPJ STAR TUP. COM. . . 

- Application FIELD-TEST configured. 

You should invoke the procedure BSL^SYSTEM:APP0003. COM 
to start this new application. 
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3.1.2 Starting Up the Application 


To start your new application* you must invoice the following 
procedure: 

t €BSLfSYSTE?1: APP0003 

%PUN-S-PROC^ID* identification of created process is 0007003A 


You can verify that the application started by looking for the 
console message* "BASE14AY is Starting." 
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3. 2 Defining Accounts 

To define accounts^ the follouiing commands should be used: 

3. 2. 1 Manager Account 


« SET DEF SYS^SYSTEM 
% RUN SYSSSYSTEM:AUTHORIZE 

ADD APPMOR/OWNER»"BASEWAY MANAGER'* - 
/UIC»C377, 3771 - 
/DiEVICE«DDCU: - 
/DIRECTORY«CTESTAPP. MGRl - 
/PRCLM-5 - 
/ASTLM-10 - 
/BYTLM-38000 - 
/BIOLM-10 - 
/DIOLM-10 - 
/FILLM-60 - 

/PRIV-(DETACH, TMPMBX, NETMBX, SYSPRV) 


3. 2. 2 User Account 


% SET DEF SYSSSYSTEM. 

% RUN SYS*SYSTEM:AUTHORIZE 

ADD APPUSR/dWNER»"BASEWAY USER"/UIC»C377, 3771 - 
/DEVICE-DDCU: - 
/DIRECTORY-CTESTAPP. USERl - 
/FLAGS-(DISCTLY, DEFCLI, CAPTIVE, LOCKPWD) - 
/PRCLM-5 - 
/ASTLM-10 - 
/BYTLM-38000 - 
/BIOLM-10 - 
/DIOLM-10 - 
/FILLM-60 - 
/PRIV-<NETMBX, TMPMBX) 
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3.2.3 Login Comoiand File 


To facilitate menu usage# the manager should set up a login 
command file for users. 

Note the flags, "DISCTLY DEFCLI CAPTIVE”, shown in the ejeample 
used in Section 3.2.2. These flags insure that the user cannot log 
into this account without executing the login command file. This 
login command file should, invoke the BASEWAY MENU program, and should 
log out when MENU exits. 

The following mag be used; 

a! 

4! Login command file 

a; 

a IF FaMUDEO .EQS. "BATCH” THEN aEXIT 
a SET TERM/INQ 

a SET TERM/NQBRO/FORM/NOWRAP 
a ASSIGN/USER 'FaLOGICAL<"TT")' SYSaiNPUT 
a ASSIGN/USER 'FaLOGICALC”TT")' TT 
a RUN BSLaSYSTEM:MENU 
a LOG/BRIEF 


The "SET TERM” commands will set up the user's terminal to 
support VAX FMS, and will support any local printer that might be 
connected. The "ASSIGN/USER" comman^is allow the MENU prog'»*am to be’ 
run from a command file. 
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3. 2. 4 


Example Accounts 


UAF>SHOW APPUSR 


Username: APPUSR Ouiner: BASEWAY USER 

Account: BASEWAY UIC: C100.2003 

CLI: DCL LOICMD; SYS^MAIMACER: SYLOGIN. COM 

Default Device: DRAl: 

Default Directory: CAPPUSR3 
Login Flags: DISCTLY DEFCLI LOCKPWD CAPTIVE 
Primary days: Mon Tue Wed Thu Fri 

Secondary days: Sat Sun 

No hourly restrictions 


PR 10: 

4 

BYTLM: 

38000 

BIOLM: 

10 

PRCLM: 

5 

PBYTLM: 

0 

DIOLM: 

10 

ASTLM: 

10 

WSDEFAULT: 

150 

FILLM: 

60 

SNQLM: 

60 

WSQUOTA: 

200 

SHRFILLM: 

• 0 

TQELM: 

10 

WSEXTENT: 

1000 

CPU: no 

1 imi t 

MAXUOBS: 

0 

MAXACCTJOBS: 

0 

PGFLQUOTA: 

10000 


Privileges: 

TMPMBX NETMBX 

UAF>SHOW APPMGR 


Username: APPMGR Ouiner: 

4 . count: BASEWAY UIC: 

DCL LGICMD: 

Default Device: DRAl: 

Default Directory: CAPPM0R3'. 
Login Flags: 


BASEWAY MANAGER 
moo. 2003 

SYS$MANAGER:SYLOGIN. COM 


Primary days: Mon Tue Wed Thu Fri 
Secondary days: 

No hourly restrictions 


PRIO: 

4 

BYTLM: 

PRCLM: 

5 

PBYTLM: 

ASTLM: 

10 

WSDEFAULT: 

SNQLM: 

60 

WSQUOTA: 

TQELM: 

10 

WSEXTENT: 

MAXJOBS: 

0 

MAXACCTJOBS 

Privileges: 



Sat Sun 


38000 BIOLM: 10 

0 DIOLM: 10 

150 FILLM: 60 

200 SHRFILLM: 0 * 

1000 CPU: no limit 

0 PGFLQUOTA: 10000 


DETACH TMPMBX NETMBX SYSPRV 
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3. 3 Startup Parameter File 


During the startup process* a "Startup Parameter File" is used to 
control the startup functions of the BASEWAY system. This allouis neui 
logical names and suhprocesses to he added uiithout modifying portions 
of the code itself. 

The commands in the startup command, file are organized into 
several groups* or sets. The order in which these sets are included 
is fixed since such things as logical names must be defined before 
subprocesses are created* etc. 

The following example shows how commands are processed by the 
Event Processor in its initialization phase: 


3-8 



Setting Up User Applications 




BASEWAY startup parameters 
SET APPLICATION ID TO 0003 

SET LOGICAL NAME BSLSDATA TO DRAO: CAPP0003. DATA! 

CREATE MAILBOX NAME BSL»MBX_PORT 010 

CREATE BASEWAY GLOBAL SECTION 

DCL eBSL*SYSTEM:EVENTLOG. COM 

DCL ®BSL«SYSTEM:NI. COM 

DCL «BSL<SYSTEM: GATEINIT. COM 


Insert application-specific logical names HERE 


; Set app1ication-specific flags HERE 


Run application-specific images HERE 
uCL SBSLeSYSTEM: DATAPROC. COM 


3.4 Modifying the Menu Facility 


BASEWAY allows the menu to be changed to reflect your 
application. You may wish to modify individual screens or menu flow 
within the screens. 

Two versions of menu support are provided with the system: 
ALL-IN-1 and MENU. Both are driven by FMS screens. To change the 
menuSi you can edit the forms found in the MENU form library in either 
the BSLSAIMENU or BSL^MENU directories. Refer to the FMS User ^s 
Reference Manual for more detailed information regarding editing of 
forms. 

WARNING: The menu forms released as part of the initial 
distribution of BASEWAY are subject to change in subsequent releases. 
Thus> any modifications made to these forms are liable to be lost. 
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For this reason/ it is suggested that, you create your tailored 
menu in the application directory that uias created uiith DEFINEAPP. COM. 



3. 4. 1 ALL-IN-1 Menu Support 


The user may leant to incorporate the menu structure into his or 
her own version of ALL-lN-1. The users of the BASEWAY system must be 
included in the ALL-IN-1 user database and these users must' have the 
SSL*A1MENU:MENU form library defined in their profiles. 


3. 4. 2 BASEWAY Menu Support 


The MENU program is distributed for systems without ALL-IN-l 
support. It is invoked by each user/ and references forms in the 
BSL^MENU:MENU form library. 


3.4.3 Modifying Keyword Options and Their Functions 


To modify a keyword option/ find the keyword definition screen 
which contains the keyword you wish to modify. Modif.y the named data 
item to do the appropriate function: 
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Named Data Commands 
MENU ALL-IN-1 


Display Si:reen 
Run Program 

Leave Program 


I MENU1iF0RM»frmnam I FORM ■Prmnam ! 

iMENU^IMAGEsfilespec ! (no equivalent) • 

I or I } 

IMENU*COMMAND«filespecI COMMAND filespec I 

JMENU^EXIT I EXIT ! 

—— - -h - - 1 . 


The MENU flow is driven from the contents of the Named Data area 
of each menu screen. The named data area must use the following 
syntax conventions: 


M£NU$FORM*<form> £/ MENU^LIB*<fi1espec>I 
MENU^IMAGE*< filespec^ 

M£NU$COMMAND*<fi1e s p e c> 

MENU^EXIT 


srh ere: 


■f orm> 

-file3pec> 


is a valid VAX FMS form name ^ 

is ^ valid VAX/VMS file specification 
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CHAPTER 4 


RELEASE NOTES 


This chapter contains information important to the installation 
and operation of BASEHAY. 

4. 1 FMS Startup Requirements 


Due to the fact that several BASEWAY and PROQRANiiABLE DEVICE 
SUPPORT images are installed/ the FMS shareable image (and error 
message file) must also be installed. This is not automatically done 
during installation/ and many sites may not have made this change in 
e FMS startup file. 

The following, change must be made: 

OLD: « ! 

S ! MCR INSTALL SYS*LIBRARY:FDVSHR/OPEN/SHARE 
^ ?• MCR INSTALL SYS*ME5SA0E: FDVSMR/OPEN/SHARE 
« ! 

NEW: « ! 

4 MCR INSTALL SYS^LIBRARY: FDVSHR/OPEN/SHARE 
< MCR INSTALL SYS*MESSAQE:FDVMSC/OPEN/SHARE 
♦ ? 


4.2 System Audit File 


BASEWAY application events are logged in the System Audit file. 
This file is a circular file containing the last 1000 events that have 
been recorded. The advantage of a circular history file is that it 
needs no maintenance. Each application has its own System Audit file/ 
normally created by DEFINEAPP.COM when the application is defined. 
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Events art rtcordtd in the Systani Audit fila by calling tha 

BSL$UOG_EVENT aervica# as dascribad in Saction 4. 21 of tha BASEWAY 
So Steffi Programmar ^ s Guide . 

Soffia applications may log avants so rapidly that 1000 avants are 

only a small snapshot/ and critical avants are lost after only a faui 

hours. Installations requiring a larger event file may create one 

uiith tha following sequence of steps: 

1. Run BSL^SYSTEM:UTLAPPSTP to shut down the application. 

2. Create a File Description Language file for tha history file: 

P ANALY2E/RMS/FDL/aUT*SYSAUD. FDL BSL<HISTORY FILE 


3. Edit tha FDL file# and change the MAX^RECORD^NUMBER parafflatar 
to one more suited to your application: 

♦ EDIT/EDT SYSAUD. FDL 

1 IDENT 31-AUG-1984 17:06:29 VAX-11 FDL Editor 

♦F'MAX RECORD NUMBER' 
eS/1000/5000/ 

13 MAXJRECORD.NUMBER 5000 

♦EXIT 

DRAl: CKONKUSISYSAUD. FDLi2 25 lines 


4. Create a new Systam Audit file.. 
S CREATE/FDL-SYSAUD. FDL 


5. Rastart your application. 


Of course/ since a new file has been created/ all of the current 
audit trail has bean lost. 

On startup# tha Event Logger process (EVENT^LDG) checks the first 
record of the System Audit file to see if it contains a valid header. 
If not/ it praaxtands the event history file to its maximunt length. 
If there are more than 10000 records/ there will be a considerable 
delay before the "BASEWAY is running” message appears on the console 
terminal screen. 
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Supporting Multiple Applications 


If more than one QASEWAY application is to communicate uiith a 
SHOP FLOOR GATEWAY systemi then it is imperative that they use a 
common database. This entails changing the SYS$MANAGER:BSLSTART. COM 
command file to define the logical name BSL^SYSDATA so it points to a 
common directory for all applications. For example# if the database 
is to reside on node VAXA ■ in the directory DRAO: CDATABASE3# then all 
copies of BSLSTART.COM should define BSL4SYSDATA as follouis: 


BSL^SYSDATA « VAXA::DRAO:CDATABASE3 


4. 4 


Using 


the Print 


Function 


There are two possible print 
PROGRAMMABLE DEVICE SUPPORT: Print 

(gold) Keypad 9). 


functions in BASEWAY and 
(Keypad 9) and Printall (PFl 


The Print function routes an image 
the session—default printer. 


of the current FMS screen to 



The Printall 
the default 
. *th the LLT menu 
entire logic list 


function 
printer, 
option 
ing to be 


lists all of the currently selected i 
For example# Printall .used in conjunc 
(Display. Ladder Listing) will cause 
routed to the,line printer. 


terns 

tion 

the 


The Print 
PROGRAMMABLE 
Printall. The 
describes the 



function is available for every screen in 
DEVICE SUPPORT. Many of the screens 
online help which is available ftsr each 
capability of the various function keys. 


BASEWAY and 
also support 
menu option 
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APPENDIX A 


SAMPLE INSTALLATION PROCEDURE 


< SET UIC Cl/41 
4 SET DEFAULT SYSSUPDATE 
4 SVMSINSTAL BSLOlO MSAO: 


VAX/VfiS Software Product Installation Procedure 


It is l-JUN-1984 at 12:05. 

Enter a question mark (?) at any time for help. 

* Are you satisfied with the backup of your system disk CYESl? YES 

Please mount the first volume of the set on MSAO:. 

♦ Are you ready? YES 

•/.MOUNT-1-MOUNTED/ BSLOlO mounted on .MSAO: 

The following products will be installed: 

BSL VI. 0 


Beginning installation of BSL VI. 0 at 12:07 
XVMSINSTAL-I-RESTORE/ Restoring product saveset A... 

Previous logical name assignment replaced 

BSLSTART.COM/ the startup command procedure/ is used to set up the 
environment for the BASEWAY Application Bus. During installation 
it will be placed in the CSYSMORl directory of the system root on 
which this installation is being performed. SYS#MANAOER: SY'STARTUP. COMi 
your system startup procedure/ should be modified to invoke this 
procedure when the system boots. However# it will not be necessary 
to reboot the system after the installation/ since this procedure 




SAMPLE INSTALLATION PROCEDURE 

invoked as part of the installation. 

>;VMSIN5TAL—I—MOVEFILES I Files will now be moved to their target directories. 
Installation Verification Procedure <JVP) starting 

The installation verification of BASEUAY Application Bus vl. 0 was successful 
Successful installation of BSL VI. 0 at 12:32 

• 

Enter the products to be installed from the next distribution volume set. 

* Products CEXITl: EXIT 


VMSINSTAL procedure done at 12:35 
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PREFACE 


1.0 Manual Objectives 


The BASEWAY Sustem Proorammer Guide is intended to describe 
BASEWAY procedures and includes syntax information« error messagesi 
and other reference information. 

2.0 Audience 


The intended audience for this manual is application programmers 
who have a basic knowledge of VAX/VMS and database concepts. 

3. 0 Prerequisites 


The reader of this manual should have an understanding of the 
VAX/VMS operating system and an in~depth knowledge of at least one 
high-level programming language. 



Structure of This Document 


This manual is organized as follows: 

Chapter 1: Describes the functions/ applications/ and 

organization of the BASEWAY system. 

Chapter 2: Describes the purpose and format of interprocess 
messages. 

Chapter 3: Introduces the system procedure descriptions detailed 
in Chapter 4. 

Chapter 4: Describes selected BASEWAY subroutines. 

Appendix A: Summarizes procedure parameter notation for BASEWAY 
cal Is. 

Appendix B: Explains the purpose/ capabilities/ and structure of 
the SHOP FLOOR GATEWAY. 

Appendix C: Provides a detailed description of the use of Device 
Interface Modules <DIMs) including an example DIM. 




Preface 


Appendix D: Oives information relevant to adding new device 
support. 

Appendix E: Slossarg. 

5.0 Associated Documents 
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0 VAX DATATRIgVE User Guide 
(order number AA-K079A-TE) 
o VAX FMS Form Driver Reference Manual 
(order number AA-L319A-TE) 

0 , VAX FMS Language Interface Manual 
(order number AA-N209A-TE) 

0 VAX FMS Uti1ities Reference Manua1 
(order number AA—L320A—TE) 

0 VAX LINKER Reference Manual 
(order number AA-D019C-TE) 
o VAX PL/I Encuclopedic Reference 
(order number AA-H952A-TE) 
o PL/I U^er Guide 

(order number AA-n95iA-7E) 
o. VAX Run-Time Libraru User's Guide 
(order number AA-L824A-TE) 

0 VAX Utilities Reference Manual 

o VAX/VMS Command Language User ^s Guide 
(order number AA-D023D—TE) 
o VAX/VMS Sustem Services Reference Manual 
(order number AA-D018C-TE) 



CHAPTER 1 


INTRODUCTION TO BASEWAY 


1. 1 Overview 


The BASEWAY system provides tools for the development and control 
of complex manufacturing applications where accurate and timely 
communication with shop floor devices is vital. These tools can 
reduce application development and maintenance time by replacing 
significant amounts of application control and programmable 
device-specific communications code. 

The BASEWAY product works together with DIGITAL'S SHOP FLOOR 
gateway product. While BASEWAY provides app‘lication program 
mmunications and control functions/ the SHOP FLOOR GATEWAY provides 
.lie actual communications interface to shop floor devices. 

Programmable devices are discrete processors that are used in 
shop floor control and data acquisition applications. These devices 
include programmable controllers/ numerical controllers/ robots/ bar 
code scanners/ and many others. Each of the devices involved with an 
application is defined to BASEWAY and identified by a unique device 
name. 

Because programmable device access subroutines allow the user to 
write an application program in a device-independent fashion/ the 
program is not tied to a programmable device or vendor. It can 
therefore be upgraded/ usually by a simple redefinition of the 
programmable device to BASEWAY. See Appendix B for a discussion of 
the GATEWAY and Appendix D for information about adding new device 
support. 

A wide rarige of manufacturing applications can be developed and 
controlled with BASEWAY/ including inventory control/ part tracking/ 
and quality control. 
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Figure 1. System Ovarview 


1. 2 Faci 1 itias 


1 Programmable Davica Access 


BASEWAY data structures* uihen used by an application program to 
^access devices# can determine device status and read and write data to 
devices. 

i. 2. 1. 1 Programmable Device Definition - 

Programmable devices are defined interactively using the BASEWAY 
configuration editor. Attributes assigned to each programmable device 
include: 


name 
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0 description or comments 
0 manufacturer name and model number 
o communications network address 
o memory size 
o physical location 
0 device type and status 
0 date of installation 

These assigned attributes are checked for validity when the 
device is defined. Up to 2000 prografttmab1e devices may be defined. 

1. 2. 1. 2 Shop Floor Data Definition - 

Individual pieces of data in a programmable device are defined 
interactively with the BASEWAY configuration editor. Such data items 
are termed “known points". Any address in a programmable device may 
be read or written when referred to by address/ but known points .may 
be referred to by point name. 

When known points are defined to the BASEWAY system/ various 
dctributes are assigned to that data. Attributes assigned to each 
known programmable device address include: 

0 address of data 

0 format of data 

0 associated equipment name 

o name of each data point 

0 minimum sample time 

0 unit descriptions 

0 destination application and process name 

Several data formats are supported. These include: 
o status conditions (single bit values) 
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o 12 bit SCD values 
o 16-bit BCD values 
0 16—bit signed binary values 


Knouin points r&ay be de^fined as monitored^ controlled/ or both, 
rionitored points are sampled at user—specified intervals by the SHOP 
FLOOR GATEWAY. Controlled points are knouin points that are written to 
by application programs. 


1. 2. 1. 3 Programming Interface - 

The BASEWAY programming interface is the means by which 
applications programs communicate with each other and with shop floor 
devices. The programming interface permits application programs to 
interact with shop floor devices in a variety of ways: 

o Generic Access allows an application program to perform 
primitive functions through device-independent routines. 
These functions include reading and writing into device 
addresses/ starting and stopping devices/ anti getting device 
attributes. 

0 Polled Access permits the SHOP FLOOR GATEWAY to periodically 
sample device data and send a message to an application 
program when data changes. 


1. 2. 2 i^BSsaging/Networking 


BASEWAY software designers may divide complex systems into 
functionally separate subsystems called "applications'*. Up to four of 
these applications may be defined to BASEWAY. These may reside on a 
single VAX CPi^tv an separate CPUs configured in a DECnet network. A 
global database contains all programmable device definitions/ and 
programs in each application can access a device simultaneously. The 
product can concurrently support up to four gateways. 

Programs communicate with each other through a messaging 
facility. Through "named message ports"/ a program can communicate 
with another program/ even if they ,are not on the same CPU. 
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1 2. 3 


Application Control 


The Application Control facility provides a controlled 
environment for application startup and shutdown. During application 
startup/ a script file is executed. This file may create logical 
names and mailboxes/ start application programs/ or perform DCL 
commands. An application program may be monitored or unmonitored. If 
a monitored application program fails/ the BASEWAY Application Control 
facility logs the event and begins an orderly shutdown of all other 
application processes. 


1. 2. 4 Session Control 


The BASEWAY Session Control facility allows a user at a VTIOO or 
yT200 series terminal to select from a menu of options and move from 
one application program to another. Each menu item may invoke another 
menu screen/ an application program/ or a command file. A sample menu 
structure is provided with the product. This structure may be 
customized on a site-specific basis by using the VAX FMS Forms Editor. 
User-written application programs may be added to the menu structure. 


1. 2. 4. 1 User Definition - 

Each user is defined to BASEWAY. A user definition ’ contains 
demographic data/ user-customization data/ privileges/ and 

application-specific data. The specific attributes that may be 
defined for each user include: 

o user name 

0 user's VMS user name 

o nickname 

o address 

o telephone number 

o title or position 

0 department 

o default line printer device 
o password for user verification 
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0 initial aianu form and form library 
o privilege masks 


1. 2. 4. 2 Tarminal Definition- 

Each tarminal devica is dafinad to BASEWAY. A tarminal 

dafinition contains privilagas and application-spacific data. If both 
a tarminal dafinition and a usar dafinition axist for tha currant 
session/ tha terminal dafinition overrides the usar dafinition. The 
attributes that- may ba defined for each tarminal include: 

0 tarminal device name 

o physical location 

o default line printer device 

o initial menu form and form library 

0 privilege masks 


1. 2. 5 Audit Trail 


The BASEWAY’Audit Trail records system events about user logins/ 
task selection/ programmable device events/ and other events. An 
associated report facility can ba used to view the information/ 
providing specific information about users and devices. 


1. 3 Functions 

The BASEWAY System consist^of a group of detached processes that 
are initially created when an application system is "started”. 

The processes that are normally active and running on the system 

are: 

Event Processor (EVENT^PROC) 

Event Logger <EVENT_LOQ) 

Network Interface (NET^INTER) 

Gateway Initializer <GA7E_INIT) 

User Application Processes 
(sample Data Processor (DATA^PROC) 
included in basic system) 
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A set of subroutines in the system 
cessary overhead of sending messages. 
_.iannelSi format interprocess messages^ 


library performs all of the 
These routines assign mailbox 
and send appropriate data. 


I. 4 Applications 


Up to four (4) applications^ running on from one to four VAX 
processors^ are supported. Each application is assigned a unique 
VAX/VMS group number> and all user programs running in the same 
application are assigned to the same group. Applications are defined 
by unique names. 
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1. 5 Access to SASEWAY Processes 
1. S. 1 Interprocess Messages 


Qenerallgi the programs running under the BASEwAY communicate 
among each other via mailboxes. Data is transmitted in data packets^ 
also referred to as "interprocess messages. " A more complete 
explanation of interprocess messages# including their formats# is 
given in Chapter 2. 


! source process i 
CALL 3SL»WRITE_MAILBGX 


——>1 destination process! 
CALL BSLfPEAD MAILBOX 


Figure 2. Interprocess Messages Betuieen Programs 
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If thff programs are not running under the same application/ they 
n still use the same mechanism to communicate with each other. The 
.SEWAY network interface programs handle all routing of the messages. 


Application ^A' 

-h - -———— - -h 

I Source Process I 

I I 

I I 

—— 1— 

BSLSWRITE_MAILBOX 


Application 'B' 

■+• - -f 

' Destination Process! 

I t 

I I 


BSL«READ_MAILBOX 
!-DECnet—M NET_INTER 

+ X +- 


I NET^INTER 

Figure 3. Interprocess Message Communication Between Applications 


BASEWAY X SHOP FLOOR GATEWAY 

X 

X 

I Application 'A' I x I Destination Task I 

r—X 

BSLSWRITE^MAILBQX x SRDMBX 

I BSL*READ_MAILBaX x ! SWRMBX 

! X ! 

V DECnet V 

I NET_INTER !->x i NET I NT ! 


Figure 4. Interprocess Message Communication Between 

Application and Gateway 
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1. 6 Data Filoa 


VAX-RMS data files are used to maintain configuration and history 
data for the BASEWAY. These files must be present at all times. They 
are: 


BSL^HISTORY.FILE 

Circular file containing a chronological 
history of BASEWAY events. 

BSL$SYSTEM_FIL£ 

Indexed file containing definitions of all 
applicationsi device sets* and gateuiays. 

3SL«DEVICE_FILE 

Indexed file containing all programmable 
device definitions. 

BSL<POLLING_FILE 

Indexed file describing sets of registers 
on a programmable device that are to be 
collected together. 

B SLiREGISTER_FILE 

Indexed file describing all polled registers 
for each of the programmable devices. 

3SL$&NTITY_FIL£ 

Indexed file containing definitions of all 
of the types of data that are collected from 
programmable devices. 

3 SL $TER nINAL_F ILE 

Indexed file containing menu information for 
a particular terminal. 

3SL«USER_FILE 

Indexed file containing session control 
information for a particular user. 
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Figure 5. BASEWAY Data Files 
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1.7 BASEWAY Proc»3s«s 


Processes on BASEWAY may be pictured as shown below: 


\ User 
I Appl. 

JPrograms 


{EVENT PPOC I- 


DATA_PR0C 
(user appl. 
processes) 


I EVENT.LOO 


i NET^INTER 


{ OATE_INIT I 


network protocol 
/ <DECnet>- 


SHOP FLOOR GATEWAY 


Figure 6. Diagram of BASEWAY Processes 


All application programs communicate with the SHOP FLOOR GATEWAY 
^ia the NET^INTER program. Any program may communicate directly with 
any other program. i 
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1.8 Event Processor (EVENT PROC) 


Ail other BASEWAY processes run as subprocesses to the Event 
Processor. EVENT_,PROC is driven at system startup time by a command 
-file uihich tells it houi to start up the other processesi as well as 
creating various group logical names/ global sections/ etc. It is 
also responsible for reporting and handling significant external 
events/ such as a link failure with a GATEWAY system and PD timeout. 


The Event Processor is responsible for the following functions: 


0 subprocess termination notice 
0 gateway failure reporting 
0 gateway event reporting 

0 establishing group logical names for application-specific 
databases 


0 establishing group-accessible global 
application-specific databases. 


sections 


for 


9 Event Logger (EVENT^LOG) 

The EVENT_,LOG process receives system events messages from 
processes through its process mailbox and Ic 
operator terminals/ the system event log file/ 
console/ or the console of the SHOP FLOOR GATEWAY. 

•V 

This process is always running on BASEWAY. 

1.10 Network Interface (NET_INTER) 


mess 

ages 

from 

oth er 

gs 

them 

to 

various 

th e 

VAX 

op erator ' s 

U-]s 

-U 

fever'd- 


can 

ckancf^ 

'fhi-i 



The primary function of this process is the routing and delivery 


of interprocess mail messages, 
mailbox or over a logical link 
messages to another processes 
a gateway. 


The process receives messages from its 
from a gateway. It then sends the 
mailbox or to the Network Interface via 

441^1 Ic^-i noli- / 


-jV 
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1.11 Gateway Initialization (QATE^INIT) 


This process continuously monitors the activity o-P the SHOP FLOOR 
GATEWAY systems and responds to significant gateway events. 

This process controls the.sequence of events which occur when a 
gateway is booted (downline system loaded). It exchanges various 
messages with the TSKWCH and GATEVP tasks in the SFG to start various 
gateway tasks running and load the polling database. 


1. 1^2 User Application Processes and Data Processor (DATA^PROC) 


These processes receive most of the data that is sent from the 
gateway as a result of device polling. They are responsible for 
formatting the data and notifying an application data processor when 
the data arrives. An example OATA^PROC is included with the basic 

system. one -p<?r cxpplim'ftcn ; app^l- acrhi^'^c 

VC 

1. 12. 1 Disposition of Polled Data 

DATA_PROC acts rather like a “sink" for polled data. In fact, 
many different polled data receivers may. be run as part of an 
application. For example, one process could receive quality data, 
another equipment fault data, etc. 
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Figure 7. Polled Data Receivers for One Application 
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1. 12. 2 Pollod Data 


Application programs running on SASEWAY normally sand 
interprocess messages to the SHOP FLOOR GATEWAY* although these 
messages may originate -Prom a task in the gateway itself. ' (See 
Chapter 2 for additional information on interprocess messages.) 


1. 13 Message Data Types 


Data types (dtype) fall into three categories: atomic^ string* 

and mi sc el laneous. 


1. 13. 1 Atomic 


Atomic data types used in BASEWAY messages are defined and 
encoded as follows: 


0 Unspecified. 

The calling program has specified no da 
type. The receiving procedure should 
assume that the data is of the corre 
'• typt. ^ 

6 Byte Integer. 

0-bit signed 2s complement integer. 

7 Word Integer. 

16—bit signed 23 complement integer. 

8 Longword Integer. 

32—bit signed 2s complement integer, 

s 

10 F^Floating. 

32-bit F^floating q.uantity representing 
a single-precision number. 

11 D^Floating. 

64—bit D^floating quantity representing 
a double—precision number. 


DSC_K_DTYPE_2 

• DSC_K_DTVPE_B 
DSC_K_DTYPEJW 
DSC_K_DTYPE_L 
DSC_K-DTYPE_F 

DSC )<( DTYPE D 
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13.2 String 


String data types used in BASEWAY messages are defined and 
encoded as follows: 


DSC_K_DTYPE_T 14 Character~Coded Text. 

A single 8-bit character (atomic data 
type) or a sequence of 0 to 65536 8-bit 
characters (string data type). 

D3C_K_DTYPE_V 1 Bit. 

An aligned bit string. A string of 
0 to 65536 contiguous bits. The first 
bit is bit 0 of the first byte and the 
last bit is any bit in the last byte. 
Remaining bits in the last byte must 
be zero on read and are cleared on 
write. 


i. 13. 3 Miscellaneous 

Miscellaneous data types used in BASEWAY messages are defined and 
..icoded as follows: 


DSC_K_DTYPE_DSC 24 Descriptor. 

This data type allows a descriptor 
to be a data type; thus^ levels 
of descriptors are allowed. 


1 . 14* Message Descriptor Prototype 


Each class of’ descriptors consists of at least one longword in 
the following format: 


31 


0 


CLASS 


DTYPE 


LENGTH 


Symbol 


Description 
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i5SC_W_LENGTH 
<Oi 15: 0> 


DSC 3 DTYPE 
< 0 , 23:16> 

DSC B^CLASS 
<0,31:24> 


1 . 14. 1 Scalar# String Dascriptor 


A singla dascriptor form is u 
strings. 


A ona-ttford -Piald spacific to the 
descriptor class# typically a 16- 
bit (unsigned) length. 

A one—byte data typa code. 


A one—byte descriptor class coda. 


DSC K CLASS «S<5S') 


for scalar data and fixed-length 


31 
















0 

1 

1 


CLASS 



1 

1 



DTYPE 

5 LENGTH 






1 

t 

f 

t 









Data 

Identifier 






f 

i 

' 1 

—r- 





One 

w 

or 

more bytes of information 



. 4 .. 

m^m 


1 

• 


Symbol 

DSC^W__LENGTH 

i2SC_B_DTYPE 
DSC^B^CLASS 
DSC L DATAID 


DSC R DATA 


Description 

Length of data in bytes# unless 
the DSC_B^DT/PE field contains 
the value 1 (bit). Length of 
data item is in bits for bit. 

A one—byte data type code. 

192 » DSC_K_CLASS_riSGS 

A longuiord containing the data 
identifier value. This value 
uniquely names the described 
data field. 

Start of the data field. 
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^ 14. 


Example DATA_PROC 


An example DATA^PROC is included in Version 1.0 of BASEWAY and is 
started by a default startup file. It logs an event th-!“ougn the Event 
Logger each time a polled data message is received. If polled dat^ is 
to be used as part of the application/ this example .may be useful as a 
starting point for creating your own polled data receiyer process. 
The source for this example is in BSL^ROOT: CSCURCE. DATAPR0C3. 
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CHAPTER 2 


INTERPROCESS f^SSACES 


2. 1 Overview 


All BASEHAY programs communicate via Interprocess Messages. 
These messages are used to exchange data and request command 
functions. 

Interprocess messages consist of two distinct areas; a fixed 
message header and an optional/ variable-length data area. The header 
contains routing information for the message and a message 
identification code. The size and format of the optional data area is 
dependent on the message identification code. 

The generic format of an interprocess message is diagrammed 
below; 


/! Message Code 

/ 

/ I Destination NAX 

header / -•---- -—- — 

\ I Source NAX 

\ ■ 4 - —- —— - — - — - — - - ■ 11.1 

\ {Source NAU ! Destination NAU 

\ * 4 * - ——— — 

message-specific I Up to 512 bytes of 

data -—} message-specific data 



Figure 8. 


Generic Interprocess Message .^^ormat 
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!vai*iabla langth ! 
i idantifiar i 
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Figura 9. Encoding of an Intarprocass Massag 














Interprocess Messages 


2. 1. 1 Message Code 


A message code is a uiord uihich indicates consent or action to be 
taken as a result of the message. Message codes 1—32767 are reserved 
for Digital Equipment Corporation. 


2. 1. 1. 1 Format of Message Code - 

15 14 13 12 n 10 9 8 7 6 5 4 3 2 1 0 


■+■ -H - - 

Bits 0—14 identify message code 
Bit 15 Ot if Digital Equipment message 
it if user message 


2. 1. 2 Source and Destination NAX 


Each application/ device set/ and gateway is assigned' a unique 
■•^-bit integer number at definition time. This number is used to 
ute messages and transactions between systems. 


2.1.3 Source and Destination NAU 


Each program in an application can have a Network Addressable 
Unit (NAU) associated with it. An NAU/ along with a NAX/ indicates a 
unique process in a network. 

There are two types of NAUs: temporary and permanent. Temporary 
NAUs are in the range -1 to -127/ and are assigned by calling the 
3SL$CREATE^P0RT routine. Permanent NAUs are created by assigning 
logical names and creating mailboxes in the EVENT^PROC startup file. 
Permanent NAUs are in the range 1 to 127: 

1—63 Reserved for Digital Equipment 
64—127 Available to user 
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2.1.4 Message*-Specific Data 


The fliessage-specific data contains information related to 
individual message. The follouiing sections u/ill define 
message~specific data formats for each message code. 


the 

the 
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2. 2 Do Generic I/O Request 


Message format: 


(16 uiords) 


—-I- 


Standard Message Header 
(4 words) 


Sequence Number 


Device logical ID 
Status Return 


Data Address 


Data Count 


Device Data Buffer 
(Optional/ 256 bytes max) 


Message Codes: MSG^GENERIC^READ 

MSG^GENERIC_WRITE 
MSG_GENERIC_WRITEVFY 
MSG_GENERIC.STARTDEV 
MSG GENERIC_STOPDEV 
MSG_GENERIC READDEVSTAT 
MSG_GENERIC_LOGONDEV 
MSG_GENERIC_LOGOFFDEV 
MSG^GENERIC STARTUPLOAD 
MSG_GENERIC.ENDUPLOAD 
MSG_GENERIC_STARTDOWNLOAD 
MSG GENERIC SNDDOWNLOAD 


Sent to: This kind of message is routed to GENSRV. It causes 
QENSRV to format and execute the request. 

Sequence Number - may be set by the requesting program. The 
GENSRV device request always returns a response message. The response 
will contain the sequence number of its command/ making this field 
usable as a synchronization aid or "sanity check. " 

Device Logical ID ^ an unsigned word value that is uniquely 
associated with each programmable device defined. 
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Status Return - not used. 

Data Address - the starting mefliory address in the progra/nmah le 
device. 

Data Count - the number of memory locations that are to be 
transferred. 

Device Data Buffer <optional> - variable length. 

Device Data Buffer (optional) - variable length. 


2. 3 Do Generic I/O Response 


Message format: 


Standard Message Header 
(4 uiords) 

Sequence Number 

Device logical ID 

Status Return 

Data Address 

Data Count 

Device Data Buffer 
(Optionali 256 bytes max) 


i (16 uiords) 


Sent to: This is sent to GENSRV and contains a status code and any 
data that tuas requested. 

Sequence Number - the sequence number of its command message. 
Device Logical ID - unchanged. 

Status Return - the status of the transaction. A value of 1 
indicates success. 












Interprocess Messages 


Data Address unchanged. 

Data Count - unchanged. 

Device Data Buffer <optional) - variable length. 
Gateway Loopback 

Message format: 


Standard Message Header 
<4 words) 

any data 




Sent to 




Th.is message is sent to NET I NT- on the gateway 



«:-/ 







Inttrprocass Massages. 


2. 5 Gat Gateway Status 


Massage format: 

Standard Massage Header (4 words) 


Status flags 
Task flags 
Error flags 
Boot time 
VDR Load time 
Gateway Counts Reset time 
Net messages sent 
Net messages received 


Net messages q.ueued 


Net messages lost 


Net fatal errors 


VDR Blocks used 


VDR size 


VDR map count 


Current gateway IB 
Current Device Sets 


Potential Device Sets 
Gateway Node name 
BASE14AY Node name 


BASEVJAY ID 


Message buffer block allocated 


Message buffer block used 
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Sent to: 

i> 

This is sent to OATEVP. 

2.6 Get Network Status for Gateway 

Message format: 

! Standard Message Header I 

I <4 words) { 

-f ---— ^ 

Sent to: 

This message is sent to NETINT on the SHOP FLOOR GATEWAY. 

2.7 Get Polled Device Statistics 

.ssage format: 

—.——--—— 

! Standard Message Header 
I (4 words) 

Sent to: 

This message is routed to POLSRV. 








Interprocess jlessages 


2. S Log Event 


Message format: 


j Standard Message Header ! 

! (4 words) ! 

I event flag > event code ! 

+ 

' variable-length text string#' 


SeTTt to*. 


This is sent to EVEWT^LOQ to initiate event logging, 


2.9 Reload VDR 


Message format: 


i Standard Message Header 
1 <4 words) 


Sent to: 


This is sent to QATEVP. 
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Reset Netu/ork Counts 


Message format: 


i Standard Message Header 
! < 4 wor d s ) 


Sent to: 


This message is sent to NETINT. 
2. 11 Set Gateway Time 


Message format: 


I Standard Message Header 
1 (4 words) 

- — —— r- 

! Year (since 1900) 

I Month 


4 — 


Day 

Hour 

Minute 

Second 


+— 


sent to* 

This message is sent to TSKWCH and causes it to set the RSX~115 
system time to the time specified by the message. 
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2. 14 Stop Oatewag 


Message format: 

i Standard Message Header 
I <4 words) 

Sent to; 

This is sent to TSKWCH. 

2. 15 Stop Polling on a Device 


Message 


format: 


+— -- —— 

I Standard Message Header ! 

1 (4 words) ' 


device id 


Sent to: 


This message is routed to POLSRV. 










CHAPTER 3 


INTRODUCTION TO SUBROUTINE DESCRIPTIONS 


Each high-iev9i language supported by VAX/VNS provides some 
mechanism for calling an external procedure and passing arguments to 
that procedure. The actual mechanism and terminology used/ however# 
vary from one language to another. Since it is not possible to 
describe the ways in which each high-level language calls system 
services.. for specific information# it is recommended that you refer 
to the appropriate high-level language user's guide. 

VAX./yNS system services are external procedures that accept 
arguments. There are three ways to pass arguments to system services: 

6 by immediate value. The argument is the actual value to be 
passed (a number or a symbolic representation of a numeric 
value). 

0 by address (also called "by reference"). The argument is the 
address of an area or field that contains the value. An 
argument passed by address is usually expressed as a 
reference name or label associated with an area or field. 
(In fact# one common error is to pass a numeric value without 
indicating that it is passed by value; if the compiler 
assumes the numeric value is an address# a run-time "access 
violation" error occurs when# for example# the image tries to 
access virtual address 0 or 1. ) 

o by descriptor. This argument is also an address# but of a 
special data structure called a character string descriptor. 


A description of each service is given in Part II of the VA.X#^VHS 
Services Reference Manua1 and indicates how each argument is to be 
passed. Phrases such as "an address” and "address of a character 
string descriptor" identify address and descriptor arguments# 
respectively. Words like "indicator#" "number#" "value#" or "mask" 
indicate an argument passed by immediate value. 
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Some services also require service-specific data structures that 
indicate functions to be performed or hold information to be returned. 
You can use this information and information from your programming 
language manuals to define such an item list. 


3. 0. 1 Testing Return Status Codes in High-Level Languages 

When a service returns control to your program^ it places a 
return status value in the general register RO. The value in the 
loui—order uiord indicates either that the service completed 
successfully or that some specific error prevented the service from 
performing some or all of its functions. After each call to a system 
service^ you must check to see whether it completed successfully. You 
can also test for specific error conditions. 

Each language provides some mechanism for testing the return 
status. Often you need only check the low—order bit> for example/ 
with a test for TRUE (success or informational return) or FALSE (error 
or warning return). 

To check the entire value for a specific return condition# each 
language provides a way for your program to determine the values 
associated with specific symbolically defined codes. You should 
always use these symbolic names when you write tests for specific 
conditions. 

The following chapter describes selected BASEWAY procedures. 
These procedures are presented by category and in alphabetical order 
by entry name. 

BASEWAY subroutines may be included in a user program by LINKing 
with the library# 3SLSLIBRARY. 


3.0.2 Compiling and Linking a VAX PL/I Program 


The text library 3SLDEF. PLI contains a variety of codes and 
routine definitions for BASEWAY. It includes most of the definitions 
that you will need for writing your own PL/I application programs. 
BSLDEF. PLI can be found in the directory BSL^LIBRARY. 

The following commands will compile and link a VAX PL/l program: 

$ PLI MYTEST 

$ LINK MYTEST#SYSSLIBRARY: BSLLIB/LIB 
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3. 0. 3 


Compiling and Linking a VAX BLISS~32 Program 


the include file BSLDEF. REQ contains a variety of codes and 
routine definitions for BASEWAY. It includes most of the definitions 
that you will need for writing your own application programs.. 
BSLDEF. REG can be found in the directory BSL^LIBRARY. 


The following commands will compile and link a VAX BLISS*-’32 
program: 

% BLISS MYTEST 

S LINK MYTEST. SYSSLIBRARY: BSLLIB/LIB 


3.0.4 Compiling and Linking a VAX FORTRAN Program 


The text library BSLDEF. FOR contains a variety of codes and 
routine definitions for BASEWAY. It includes most of the definitions 
that you will need for writing your own FORTRAN application programs. 
BSLDEF. FOR can be found in the directory BSL^LIBRARY. 

The following commands will compile and link a VAX F0RTRAf*4 
program: 

s FORTRAN MYTEST 

LINK MYTEST. SYS$LIBRARY: BSLLIB/LIB 


3.0.5 Compiling and Linking a VAX BASIC Program 


The include file BSLDEF. BAS contains a variety of codes and 
routine definitions for BASEWAY. It includes most of the definitions 
hat you will need for writing your own BASIC application programs. 
SLDEF. BAS can be found in the directory BSLSLIBRARY. 

The following commands will compile and link a VAX BASIC program: 

S BASIC MYTEST 

% LINK MYTEST. SYS$LI3RARY:BSLLIB/LIB 
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3.0.6 Compiling and Linking a VAX C Program 


The includa fila 3SLDEF. H contains a variatg of codas and routina 
definitions for BASEWAY. It includes most of the definitions that gou 
uiill need for writing g-our own C application programs. BSLDEr. H can 
be found in the directory BSL^LIBRARY. 

The following commands will compile and link a VAX C program: 

^ CC MYTEST 

% LINK MYTEST, SYS^LIBRARY;BSLLIB/LIB 


3.0.7 Compiling and Linking a VAX COBOL Program 


The copy file BSLDEP. LIB contains a variety of codes and routine 
definitions for BASEWAY. It includes most of the definitions that you 
will need for writing your own COBOL application programs. BSLDEF. LIB 
can be found in the directory BSLSLIBRARY. 

The following commands will compile and link a VAX COBOL program: 

^ COBOL MYTEST 

e LINK MYTEST, SYS«LIBRARY: BSLLIB/LIB 


3. 0. S Compiling and Linking a VAX PASCAL Program 


The definition file BSLBEr. PAS contains a variety of codes and 
routine definitions for BASEWAY. It'includes most of the definitions 
that you will need for writing your own Pascal application programs. 
BSLDEF. PAS can be found in the directory BSL^LIBRARY. 

The following commands will compile and link a VAX PASCAL 
program: 

s PASCAL BSLDEF/ENVIRONMENT 
S PASCAL MYTEST 

e LINK MYTEST, BSLDEF.. SYS^LIBRARY; BSLLIB/LIB 
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3. 1 Hou» To Use Procedure Descriptions in This Manual 


Each procedure description consists of the following categories. 
Certain procedures have an additional "Notes" section. 

NOTE: All of the procedures described in this document return a 

completion status condition code as a function return value. 

Calling Format: 

This section shores ttre errtrg name and a generalized format for 
calling the procedure from a high'-level language^ with all 
arguments listed in positional order. Spaces between arguments 
are present for readability and are not part of the statement 
syntax. 

Arguments: 

This section describes each of the arguments in detail/ along 
with any special argument-passing requirements. 

Return Status: 

This section lists the possible error return status codes from 
the procedures# with an explanation of the return condition. The 
returns are listed in alphabetical order. All status codes are 
severe errors# unless otherwise indicated. 

Usage Restrictions: 

This section notes any user privileges that are required# and any 
special conditions that must be established prior to calling this 
procedure. 


jNo tes: 


S Th i s optional section contains a detailed usage description of 
the procedure# as well as references to related information. 
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CHAPTER 4 


SELECTED BASEWAY SUBROUTINES 


. 1 Overview 


This chapter contains descriptions of various 3ASEWAY subroutine 
hat are useful in supporting interprocess messages and the readin 
nd writing of records. 

NOTE: Subroutines specific to programmable device access are 
enoted by the letters PDA. 
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4.2 BSL-SACCESS^DEVICE - Access a Progranwnafa le Device (PDA) 


3SL«ACCESS DEVICE 


The Access Programmable Device procedure provides a means of 
establishing an access path to a specified programmable device and 
setting a default programmable device name. No data is returned bg 
this call. 

If a programmable device name is not specified# then the last 
used programmable device name is used. If a handle is not specified# 
a default handle is used. 

Note that an implicit BSL^ACCESS call is performed bu all of the 
other BSL routines. 

Calling Format: 

BSL$ACCE53_DEVICE ( Chand lei# Cdevicel) 

Arguments: 

handle. . ' 

Optional address of a longword to be used as an internal context 
identifier. A programmer ma-y choose to keep several handles# 
each with a different context. This parameter must be 
initialized to 0 before being specified for the first time in a 
call# and not modified thereafter. If this parameter is not 
specified# the system will supply a default context identifier. 

device 

Optional address of a character string descriptor pointing to the 
text string naming the programmable device. This programmable 
device name string must correspond exactly to’ the name of the 
device requested. If this parameter is not specified# the last 
referenced programmable device is used. 



Sfflecttd BASEUAY Subroutines 


Return Status: 

L$_NORMAL 

Service successfully completed. 

33L$.NOSYSTEM 

The programmable device does not have a valid device set 
associated with it. 

3sl$.pdevdef;lt 

The caller did not specify a programmable device name^ and did 
not have a default name set. 

3SL$_NOPDEV 

The programmable device that was specified does not exist. 


'v 
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4. 3 BSL^ACCESS POf?T - Access Another Port. 


BSL^CCESS PORT 


The Access Port procedure will find the Port value for a 
particular named port currently running on an applicatioHi device set/ 
or gateway. 

This port value directly and uniquely identifies a message port 
somewhere in the system. 

Calling Format: 

BSL^ACCESS^PORT v port# Csysteml# port^name# ) 

Arguments: 

port 

Address of a longword to receive the* port value. Port values are 
32-bit values that uniquely identify the message port. 

3 y 31 em 

Optional address of a descriptor pointing to a character string 
that contains the name of the application.* device set., or 
gateway. If this parameter is not specified/ the name of the 
current application is used. 

port^name 

Address of a character string descriptor pointing to the tex 
string containing a valid message port name. These names ar 
unique to an application or gateway. 
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Return Status: 

L^.NOBSL 

A BASEWAY application is not currently running in this UIC group. 
BSL^.NORMAL 

Service successfully completed. 

3S«_INSFAR0 

Not enough arguments mere passed to the routine. * 

BSLS.NOBSL 

No BASEWAY application is running. 

BSL«_NOPORT 

If the port is local to the current application/ then the 
specified port name does not exist. If the port is remote.- then 
the problem may be uiith the Netuiork Interface port. 

3SL$_NOSYSTEN 

The application/ device set/ or gateway does not exist. 
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4.4 BSL-iALLOCATE^DEVICE - Allocate a Programmab le Device (PDA) 


BSL$ALLaCATE DEVICE 


The Allocate Progra/nmab le Device procedure provides a means of 
requesting exclusive access to a programmable device. This call is 
often used prior to downline load a device and during complicated 
diagnostic functions# where it is imperative that no other process 
access the device. If a programmable device name is specified# then 
the current default programmable device name is set to the specified 
name on completion of this call. 

Calling Format: 

BSL«ALLQCATS_DEVICE < Chandlel# Cdevicel# Cflagsl ) 

Arguments: 

handle 

Optional address of a longtuord to be used as an internal context 
identifier. A programmer may choose to keep several handles# 
each with a different context. This parameter must . be 
initialized to 0 before being specified for the first time in a 
call# and not modified thereafter. If this parameter is not 
specified# the system will supply a default context identifier. 

device 

Optional address of a character string descriptor pointing to the 
text string naming the programmable device. This programmable 
device name string must correspond exactly to the name of the 
device requested. If this parameter is not specified# the last 
referenced programmable device is used. 

flags 

Optional address of a word containing flags. If the first bit is 
set in this flag word# then any automatic data collection 
(polling) of this device is stopped while the device is 
allocated. If clear# then data collection continues but all 
other access is denied. 
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Return Status: 
jL«_NOBSL 

A BASEWAY application is not currently running in this UJC group. 
BSL«_NORMAL 

Service successfully completed. 

SSL^.NOSYSTEM 

The programmable device does not have a valid device set 
associated with it. 


BSL* OWNATTACHED 


The programmable device that was specified is currently allocated 
by this process's parent process/ and therefore.- can be 
considered allocated to this process. 


5SL* PDEVDEFLT 


The caller did not specify a programmable device name.- and did 
not have a default name set. 


i^SL^.NOPDEV* ' * . , 

The programmable device that was specifieddoes not exist. 


BSL* ATTACHED 


The programmable device is currently allocated to another 
process. 
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4.3 BSL’*CdMPARE_DEVICE - Compare Programmable Device Logic (PDA) 


BSLSCOMPARE DEVICE 


The Compare Device Logic procedure will compare two programmable 
device logic files and report any differences to the caller. 

Not all programmable devices support the compare function. 

Calling Format: 

BSL^COMPARE_^DEVICE < Chandlel, Cdevicel, filename ) 

Arguments: 
handle 

Optiona^l address of a longword to be used as an internal context 
identifier. A programmer mag choose to keep several handles^ 
each with a different context. This parameter must be 
initialixed to 0 before being specified for the first time in a 
call/ and not modified thereafter. If this parameter is not 
specified/ the sgstem will supply a default context identi.fier. 

device 

Optional address of a character string descriptor pointing to the 
te.xt string naming the programmable device. This programmable 
device name string must correspond exactly to the name of the 
device req.uested. If this parameter is not specified/ the last 
referenced programmable device is used. 

filename 

Address of a character string descriptor pointing to a VAX/VMS 
file containing a programmable device logic dump for a similar 
programmable device. 
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Return Status: 

L$_COMPFAIL 

The compare failed due to one or more differences in the logic 
file and the programmable device's memory. 

5SL«_NOBSL 

A BASEWAY application is not currently running in this UIC group. 
BSL$_NORMAL 

Service successfully completed. 

2SLS_NOSYSTE« 

The programmable device does not have a valid device set 
associated with it. 

5SL«_NOT3UPPORTED 

The programmable device does not support this function. 
f53L$_PDEVDEFLT 

The caller did not specify a programmab1e device “name/ and did 
not have a default name. set. 

25L$_NOPDEV 

The programmable device that was specified does not e.xist. 
B3L$_ATTACHED 

The programmable device is currently allocated to another 
process. 
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4. 6 BSL^COMPILE__DEVICHEADDRESS — Precompile an Address (FDA) 


SSLSCCnPILE DEVICE ADDRESS 


The Compile Address procedure allows a caller to translate a 
character string containing a valid programmable device address into 
an internal format. This internal format mag be substituted for the 
character string device address in other BSL calls. 

Precompiling addresses that are to be used over and over can save 
a substantial amount of overheads as the address string does not have 
to be parsed each time. 

Calling Format: 

3SL$CQMPILE_D£VIC£_ADDRESS < Chandlel, Cdevicel. address. 

compiled ) 


Arguments: 

handle 

Optional address of a longword to be used as an internal context 
identifier. A programmer mag choose to keep several handles, 
each .with a. different ^context.- This parameter .must be 
initialized to 0 before being specified for the first time in a 
call, and not modified thereafter. If this parameter is not 
specified, the sustem will supply a default conte.xt identifier. 

device 


Optional address of a character string descriptor pointing to the 
text string naming the programmable device. This programmable 
device name string must correspond exactly to the name of the 
device requested. If this parameter is not specified, the last 
referenced programmable device is used. 

address 

Address of a character string descriptor pointing to the text 
string containing a valid programmable device address. 
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compiled 

Address of a descriptor pointing to a character string to receive 
the compiled address. The character string must be at least 33 
bytes long. 

Return Status: 

BSL$_NORMAL 

Service successfully completed. 

BSL$_IMuSYSTEM 

The programmable device does not have a valid device set 
associated itfith it. 

BSL«_^40TS.UPP0RTED 

The programmable device does not support this function. 

BSL$_FDEVDEFLT 

The caller did not specify a programmable device name.- and did 
not have a default name set. 

BSL'S.NOFDEV 

The programmable device that uias specified does not exist. 
BSL$_BADADDR 

The address specified in the ‘'ADDRESS'* parameter has an illegal 
syntax or is outside of the range of valid addresses for this 
programmable device. 
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4. 7 3SL4»CREA7E^?1E5SAOE - Craata an Intarprocass Massage 



3SL$CR£ATE MESSAGE 


The Craata Massaga procadura allocates space for an intarprocass 
message^ optionally sets soma default massage attributes/ and returns 
a pointer to the massage. 

Messages that are created using this procadura should only be 
deleted with the BSL^DELETE^MESSAGE procedure. 

Calling Format: 

3SL^CREATE_M£SSA5E < pointer/ Csizel/ Ccodel/ 

Cdest^ortl/ Csourcejortl ) 

Ar g ument s: 
pointer 


Address of a longword to receive the address of the data portion 
of the massage. 



Optional address of a word containing the size of the data 
portion of the allocated message. Valid values are in the range 
of 0 to SOOO bytes. If no size parameter is specified/ then the 
default ma.ximum size of 8000 bytes is used. 

cods 

Optional address of a «iiord containing the message code to be 
assigned to this message. If no code is specified.- then a cods 
must be specified in the BSL^SEND^MESSAOE procedure call. 

c e st^ or V 

Optionai'address of a iongword' containing the port value of the 
port that this message is to be sent to. If no des t_port is 
specified/ then a destination port must be specified in the 
BSL^SEND^MESSAOE procedure call. 
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5curce_port 

Optional address of a longword containing the port value of the 
port that this message is to be sent from. 

Return Status; 

BSL*_NORMAL 

Service successfully completed. 

53$_INSFARG 

Not enough arguments were passed to the routine. 

BSL«_BADMSGSI2E 

The interprocess message size that was specified is outside of 
the range of 0 to SOOO bytes. 
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4.8 BSL$CREATS_NAMED_PORT - Craata a Parmanant Massage Pert 


3SL$CRSATE NAMED PORT 


The Create Named Port procedure allocates a permanent message 
port# associates an applicationuiide name uiith it# and assigns it to 
the calling process. Interprocess messages may then be read from and 
uiritten to this port. 

Message ports created ufith this procedure should be deleted via 
the 3SLSDELETE_PaRT procedure. 

Calling Format; 

BSLSCREATE NAMED PORT < port# name# Csizel# Cgueuadl# 

Cidl# ) 


Arguments: 


port 


Address of a longuiord to receive the port value. “ort values are 
32-bit values that uniquely identify the message port. 

name 

Address of a character string descriptor pointing to a tex 
string containing the name to associate with this port. Name 
must be alphanumeric symbols# and can be no more than 2 
characters in length. 

size 

Optional address of a word containing the maximum size of a 
message that can be received through this port. ^‘alid values are 
in the range of 0 to 8000 bytes. If no size parameter is 
specified# than the default maximum size of 8000 bytes is used. 
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queued 

uiord containing the maximum number of 
queued to this port at any one time. If no 
then a default value of 10 is assumed. 

id 


Optional address of a 
messages that can be 
maximum is specified^ 


Optional address of a word containing a numeric identifier for 
this port. Ports that are to receive polled data messages from a 
gateuiay must be assigned a unique ID number by the system 
manageri and use this number each time this port name is created. 


Return Status: 


BSL«_NCBSL 

A BASEWAY application is not currently running in this UIC group. 
S3L$_N0RMAL 

Service successfully completed. 
bB$_INSFARO 

Not .enough arguments u^ere passed to the routine. 

BADMSOSIZE 


The interprocess message size that was specified is outside of 
the range of 0 to 3000 bytes. 

3SL$_N0BSL 

No BASEWAY application is running. 

3SL$.P0fiTEXIST5 

A port with this name or ID already exists. 

BSL^^TOCfMANYPORTS 

More than 127 named ports are currently in use by this 
application. 
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4.9 BSL^CREATE_PORT - Create a Temporary Message Port 


33L$CR£ATE PORT 


The Create Port procedure allocates a temporary message port and 
assigns it to the calling process. Interprocess messages may then be 
read from and written to this port. 

Message ports created with this procedure should be deleted via 
the BSL^DEUETE^PORT procedure. 

Calling Format: 

3SL$CREATE^PCRT < port^ Csixel# Cqueued!/ ) 

Arguments: 

port 

Address of a longword- to receive the port value. Port values are 
32^bit values that uniquely identify the message port. 

size 

Optional address of a word containing the ma.ximum size of a 
message that can be received through this port. valid values are 
in the range of 0 to 3000 bytes. If no size parameter is 
specified/ then the default ma.ximum size of 3000 bytes is used. 


Optional address of a word containing the ma.ximum number of 
messages that can be queued to this port at any one time. If no 
maximum is specified/ then a default value of 10 is assumed. 
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L«_NOBSL 

A BASEWAY application is not currently running in this UIC group. 
3SL$.NORMAL 

Service successfully completed. 

S3$_INSFAR<3 

Not enough arguments u/ere passed to the routine. 

BSL^.BADMSGSIZE 

The interprocess message si2e that was specified is outside of 
the range of 0 to 6000 bytes. 

BSL$ NOBSL 


No BASEWAY application is running. 

3SL$_N0NAU 

f^ore than 127 temporary ports are currently in use by this 
application. 
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4. 10 BSL^CVT^IiX_DX - General Data Type Conversion Routine 

aSL^CVT MX DX 


The Convert Message Descriptor to Data Descriptor procedure 
converts a data item described by a BASEWAY ntessage descriptor to a 
VAX standard data descriptor. 

Calling Format: 

BSLSCVT^MX^DX < src^desc/ dest^desc^ dest^len ) 

Arguments: 

src_desc 

Address of a BASEWAY message descriptor. These descriptors are 
used to identify pieces of data being sent in Interprocess 
messages. 


dest^desc 


Address of a VAX descriptor pointing to a piece of data. Any 
data conversions necessary to convert the source data into the 
destination data are performed> - and the resulting data is copied 
to the -memory pointed to by'the destination descriptor. 



dest^len 


Address of a word to receive the length of the data ite.m. 
returned from the dest^desc parameter for convenience. 


Th i 3 
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eturn Status: 

*-$_NORMAL 

Service successfully completed. 
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4.11 SSL^DATA^TYPS - Find Data Type for a Programmabis Device.Address 
(PDA) 



3SL$DA7A TYPE 


Programmable devices contain a ufide variety of data formats and 
data sizes. The Data Type procedure checks the validity of a 
programmable device address and returns the physical data type found 
at this address. 

Calling Format: 

BSLSDATA^TYPE ( Chandle^/ Cdevicel# address/ type ) 

Arguments: 


handle 


Optional address of a longuiord to be used as an internal context 
identifier. A programmer may choose to keep, several handles/ 
each uiith a different context. This parameter must be 
initialized to 0 before being specified for the first time in a 
call/ and not modified thereafter. If this parameter is not 
specified/ the system will supply a default context identifier. 



device 


Optional address of a character string descriptor .oointing to the 
te.tt string, naming the programmable device. This programmable 
device name string must correspond exactly to the name of the 
device req.uested. If this parameter is not specified/ the last 
referenced programmable device is used. 


3d dress 


•Address’ of a character string descriptor pointing to the 
string containing a valid programmable device address. 
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~Mpe 

Address of a word to receive the type of data referred to by the 
specified address: 


BSL^K TYPE BIT 

Bit data 

BSL«K TYPE BYTE 

Byte data 

BSL^K TYPE WORD 

Word data 

BSL«K_TYPE_LONG 

Return Status: 

BSL$_NORMAL 

Longword data 


Service successfully completed. 
3SL$ NOSYSTEM 


The programmable device does not have a valid device set 
associated with it. 

?53L$_NOT3UPPORTED 

The programmab1e device does not support this function. 
■;L$_PD£VDEFLT 

The caller did not specify a programmable device name.- and did 
not have a default name set. 

B3L$__NDPDEV 

The programmable device that was specified does not exist. 
BSL$_B.ADADDR 

The address specified in the "ADDRESS" parameter has an illegal 
syntax or is outside of the range of valid addresses for this 
programmable device. 
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4. 12 3SL$DEACCESS_D£VICE - Oeaccess a Programfliab1e 


Device (PDA) 


3SL$DEACCESS_DEVICE 

The .Oeaccess Prograiamable Device procedure provides a means of 
disassociating an access path teith a specified programmable device/ 
and clearing the default programmable device name. No data is 
returned bg this call. 

Calling Format: 

BSL*DEACC£SS_^DEVICE < Chandiel ) 

■AT'-5--ci*»Tv-e-rft»: 
handle. 

Optional address of a longu/ord to be used as an internal context 
identifier. A programmer mag choose to keep several handles/ 
each uiith a different context. This parameter must be 
initialized to 0 before being specified for the first time in a 
call, and not modified thereafter. If this parameter is not 
specified,, t^fe ^eiil sxjppl^ a default context identifier. 

Return Status: 

R 3 MAL 

Service successfullg completed. 

I5SL^_POEVD£FLT 

The caller did not specifg a programmable device na.-nai and did 
net have a default name set. 

JrSL^JMOrDEV 

The programmable device that uias specified does not exist. 
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. 13 S5L'$DEALL0CATE_DEVIC£ - Deallocate a Programmab 1 e Device (PE>A.) 


i C 1all 


The Deallocate Program/nab le Device procedure provides 
easing an allocated prograiTiffiafa ie device so that 
ess it* and so that automatic data collection can 
rammabis device nams is specified/ then the 
rammable device name is set to the specified name 


means of 
otner users can 
resume. I f a 
current default 
on completion of 


a i i ints r crinat: 


BSL^DEALLOCATE 


Chandlel/ Cdevice 3 > 


r g u m e n t s! 


Optional address of a iongu/ord to be used as an internal context 
identifier. A 'programmer may choose to keep several handles^ 
ujith a different context. This parameter must be. 

initialized tc 0 before being specified for the first time in a 
c«:i. and n :t modified thereafter. If this parameter is not 

specified/ the systesr, '.uill supply a default context identifier.. 


Optional address of a character string descriptor pointing to the 
te;<t string naming the programmable device. This programmable 
device name string must correspond exactly to the name of the 
ds'/ice requested. If this parameter is not specified/ the last 
referenced programmable device is used. 
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Return Status: 

DSL^^NOBSL 

A BASEWAY application is not currently running in this UIC group. 
BSL<_NORMAL 

Service successfully completed. 

B3LS_N0SYSTEM 

The programmable device does not have a valid device set 
associated uiith it. 

3SL«_aWNATTACHED 

The programmable device that teas specified is currently allocated 
by this process's parent process# and therefore# is not 
deallocated. 

BSL^^NOTATTACHED 

The programmable device that uias specified in the deallocate 
operation is not currently allocated by the calling process. 

BSL^.PDEVDEFLT 

The.caller did hot specify a programmable device name#- and did 
not have a default name set. 

3SL$_NGFDEV 

The programmable device that uias specified does not exist. 
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4. 14 


SSL$DELETE.MESSAOE 


Delete an Interprocess Message 


BSL^DELETE MESSAGE 


The Delete Message procedure deallocates space 
interprocess message occupies. 

Calling Format: 

BSL$DELETE_MESSAGE (pointer > 

Arguments: 
pointer 


Address of a iongword to receive, the address of the data 
of the message. 

Return Status: 

5SL$_NuRMAL 

Service successfully completed. 


that an 


p ortion 
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4. 15 


BSL«DEL£TE_FORT - Delete a Message 


Port 



BSL^DELETE.PORT 


The Delete Port procedure frees up a message port that uias 
assigned to the calling process. 

Calling Format: 

BSLSDELETE^PORT < port ) 

.Arguments: 

port 


Address of a longuiord to receive the port value. Port values are 
32-bit values that uniquely identify the message port. 

•Psturn Status:* 

3SL«_NCBSL 


A BASEWAY application is not currently running in this UIC group. 
35L$3‘CHMAL 

Service successfully completed. 

33$_INSF.ARC 

Not enough arguments uiere passed to the routine. 


B3L$J4CPORT 

The specified port does not exist# or is 
calling process. 


•n e 



not assigned 
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4, 16 BSL^DOWNLOAD DEVICE - Download Logic to a 

^ (PDA) 


Programmable Device 


BSL^DOWNLOAD DEVICE 


The Download Programmable Device procedure provides a means of 
loading a VAX/VMS file containing device logic into a programmable 
device. 


Not all programmable devices support this function. 

Calling Format: 

SSL^DOWNLOAD_^DEVICE ( Chandlel/ Cdevicel/ filename ) 

Arguments: 
hand 1e 

Optional address of a longword to be used as an internal context 
identifier. A programmer may choose to keep several handles/ 

. each with a different context.. This parameter must be 
initialized to 0 before being specified for the first time in a 
call/ and not modified thereafter. If this parameter is not 
specified/ the system will supply a default context identifier. 

device 

Optional address of a character string descriptor pointing to the 
text string naming the programmable device. This programmable 
device name string must correspond exactly to the name of the 
device requested. If this parameter is not specified/ the last 
referenced programmable device is used. 

filename 

Address of a character string descriptor containing a VAX./vMS 
filename of a file that contains programmable device logic for a 
similar device. 
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Return Status: 

BSL$_NCBSL 

A BASEWAY application is not currently running in this UIC group. 
33L$_NGRMAL 

Service successfully completed. 

SSLS_^4CSYSTE^f 

The programmable device does not have a valid device set 
associated uiith it. 

B3L^.N0TSUPP0RTED 

The programmable device does not support this function. 
S5L$_PD£VDEFLT 

The caller did not speciry a programmable device name^ and did 
net have a default name set. 

iiSLS^NCPDEV 

The programmable device that uia.s specified does not exist. 

•: SL'S^ATT.ACHED 

The programmab ie 'device is currently allocated to another 
process. 

s 
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V. 17 B3L$SET__DATA__INF0 — Get Data In-Formation 


ESLSQET DATA INFO 


The Get Data In-Formation procedure provides inFormation about a 
piece of data knouin to BASEWAY. In-Formation available includes 

data type^ name> internal identifier* etc. 

Calling Format: 

BSL$GET_DATA__INFO < Cidl* Cnamel* item_list ) 

Arguments; 


Optional address of a longuiord containing the data 
identifier value. 

name 

Optional address of a character string descriptor pointing 
to the name of this piece of data. Either the ID or the 
NAME parameter must be specified. 

»m_li5t 

Address of a list of item descriptors that describe specific 
attributes that are requested* and point to the buffers to 
receive the information. 

Return Status: 

E3L$JM0RMAL 

Service successfully completed. 

BSL'S^NGDaTA 

The data point specified by either a name or an ID does not exis 

B 5 L ■$ __ IN V C ALL 

Neither the name or ID was specified 
I3SL$ TRUNC 


User-specified buffer to receive the data was too small. 
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Not«s: 

The item descriptors in the item list have the following format: 



31 

16 15 

0 



———► 

1 

1 

item code ! buffer length 

1 

1 

I 

t 

buffer address 

t 

t 

1 

t 

return length address 

1 

1 


The format of the item list is described in Section 2. 3. 3 of the 
VAX/VflS Sastern Services Reference Manual . The ite-m codes for the 
procedure call are described in the table below. 


Item Identifier 

{2SL^K_DI_DID 
I3SL«K DI NAME 
I 3SL1JK DI_FLA«S 


Data Tgpe 

1 Information Specified 

1 

1 

value 

* Data point internal identifier 

i 

string 

! Data point name 


! 

t 

value 

I* data point status 

flags 







iSgmbol 1 

Meaning 

J 


IBSLSM DI STATUS 

status Doint 

1 


.‘BSL^M DI VALUE ! 

value point 

i 


1 BSLSM_DI_STRUCTUP.E 

structure of 

t 


t 

t 1 

points 

i 


1BSL^M_DI_0PQUP 1 

-- - - -—--- 

point group 

f 

! 
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I 4. 18 BSL'JGET DEVICE ATTRIBUTES - Get Device Attributes (PDA) 

W 


BSL^GET DEVICE ATTRIBUTES 


The Get Attributes procedure provides allocation/ definition/ and 


status information about a programmable device, 
to determine whether a device is in a proper 
loading and to write device status reports 
programmable device name is specified/ then 
programmable device name is set to the specified 
V ii 13 call. 


This call may be used 
state for downline 
and ut.i. 1 ities. If a 
the current default 
name on completion of 


Calling Format: 

BSL^GET_DEVICE_ATTRIBUT£S ( Chandlel/ Cdevicel/ item^iist ) 
Arguments; 

;randie 


Optional address of a longword to be used as an internal context 
identifier. A programmer may choose to keep several handles/ 
each with a different context. This parameter must be 
initialized to 0 before being specified for the first time in a 
call/ and not modified thereafter. If this parameter is not 
specified/ the system will supply a default context identifier. 


c 5 V 1 c e 


Optional address of a character string descriptor pointing to the 
text string naming the programmable device. This programmable 
device name string must correspond exactly to the name of the 
device requested. If this parameter is not specified/ the last 
referenced programmable device is used. 

i tem_list 

Address of a list of item descriptors that describe specific 
attributes that are requested/ and point to the buffers to 
receive the information. 
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.Saturn Status; 

SSL^.MOBSL 

A BASEWAY application is not currently running in this UI 
SSL$ NORMAL 


Service successfully completed. 

BSL^J'iCSYSTEM 

The programmable device does not have a valid device set 
associated tuith it. 

jSL^.PDEVDEFLT 

The caller did not specify a programmable device name and did not 
have a default name set. 


NOPDEV 


The programmable device 


that uias specified does not exist. 


. o 
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N 0 10 5 1 


The item descriptors in the item list have the following format 


31 


16 15 


item code 


buffer length 


buffer address 


return length address 


The format of the item list is described in Section 2.3.3 of the 
VAX/VMS Sustem Services Reference Manual . The item codes for the 
procedure call are described in the table below. 
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. B5L^_^_DA_LDCATI ON 

string 

Location description string ? 

i2SL^K_DA.DESCRIPTICN 

string 

Device description string 1 

1 BSL«K_DA_CONTRACTOR 

i 

str ing 

Contractor description string 1 

1 

13SL«K_DA.NET_NAME 

» 

string 

Communications Network name ! 

I 

; 3SL*K.DA_DEVICE_SET 

I 

string 

Device set associated with this device ! 

! BSL^K.DA.GATEWAY 

string 

Gateway currently communicating with ! 

! 


this device 1 
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4. 19 BSLf<3ET^SESSION_INFO - Ratriava Currant Sassion In-formation 


a wL’^5ET_SESS I ON^I jVr u 


Tha Oat Saasion Information procadura providas information about 
tha currant tarminal sassion. Information available includas current 
privilagaSi default menu forms# default printers# ate. 

• This procedure may. only be called in the context of an 
interactive process. 

Calling Format: 

BSL«OET_SESSiaN_INFC ( item^list ) 

Arguments: 

item^list 

Address of a list of itam descriptors that describe specific 
attributes that are requested# and point to the buffers to 
receive the information. 

Return Status: 

j3SL$_NCBSL 

A BASEWAY application is not currently running in this UIC group. 
SSL$_NORMAL 

Service successfully completed. 
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Notes: 


The itefli descriptors in the item list have the following format 
31 16 15 0 

+-—- - h - 4- 

! item code ! buffer length ! 

I buffer address I 

return length address I 


The format of the item list is described in Section 2.3.3 of the 
VAX/VMS Sustem Services Reference Manual . The item codes for the 
procedure call are described in the table below. 



4-37 






Selfctad BASEWAY Subroutin«s 


— — ” — — —1^ — ■ — ——— — — -i — 

I It*m > .D»ta > * 

I Identifier } Type } Information Specified ' 


1 BSL<K_SI»_TERMINAL 

string 

Terminal device name 

1 J3SLSK_SI_USERNAME 

string 

VAX/VMS user name 

iaSL4K_Sl_NA«E 

string 

User's name 

! B SL1!K_S I _N ICKNAME 

string 

User's nickname 

I3SL«K_SI_ADDR 

string 

User's address 

•‘BSL^K^S I-PHONE 

string 

User's phone number 

iBSLSK^SI^TITLE 

string 

User's title or position 

:BSL^K_SI_DEPARTHENT 

string 

User's department name 

!3SL^K_SIMPRINTER 

string 

Default printer for this'session 

I3SL^K_3I_PRIVS 

string 

Privilege mask for this session 

i 5SL15K_SI_CUST_PRIVS 

string 

Customer—defined privileges 

5SL^K_SI_LOCATION 

string 

Terminal location description 

1 

f 


Sfg0. 
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4.20 BSL$OET_SYSTEM.INFO - Get System Attributes 


BSLfGET SYSTEM INFO 


The Get System Information procedure provides definition and 
status information about an application^ device set> or a gateway. 

The system may be selected by specifying either a NAX or a system 
name. If neither are specified# then the current ap.p 1 ication 's 
attributes are returned. If a system name of is specified# then a 

:.ijildcard lookup is performed# and each successive call returns another 
system until the status code BSL^^NOSYSTEM is returned. 

Calling Format: 

BSLSGET^SYSTEM^INFO < CnaxI# Cnamel# item^list) 

.Arguments: 
na X 


Optional address of a word that contains a system internal 
identifier. 


name 

Optional address of a character string descriptor pointing to the 
text string naming the application# device set# or gateway. 

it em_li51 

Address of a list of item descriptors that describe specific 
attributes that are requested# and point to the buffers to 
receive the information. 
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Return Status: 

BSL^.NCBSL 

A BASEWAY application is not currently running in this UIC group. 
3SL$_NORMAL 

Service successfully completed. 

BSL^.NCSYSTEM 

The specified system does not exist# or there are no more systems 
if this was a wildcard lookup. 

•Notes: 


The item descriptors in the item list have the following format 


31 


16 15 


item code ! buffer length 

buffer address 




return length address 


The format of the item list is described in Section 2.3.3 of 
vAX/VfIS System Services Reference Manual . The item codes for 
procedure call are described in the table below. 


the 

the 
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' I tent 

1 Identifier 


:BSL^K_AI_ID 

IBSL^K_AI_NA«E 

iQSL.^K_AI_FLAGS 


iSSL^K AI DESCRIPTION 


|D^9 

1 

Information Spe 

c if isd 

1 

f 

1 

t 

value 


System internal identifier number 

{ 

1 

1 

1 

1 

string 

» 

System name 


1 

1 

> 

1 

value 


System status flags 


t 

1 

1 


• Symbol 

} Meaning 

! 

t 


IBSL^M AI APPLICATION 
JBSL^W.AI DEV1CE5ET 

\ BSL«M_AI.GATEWAY 

1 

I 

J BSL^M_AI_REACHABLE 
-- ——— 

• Application 
\ Device Set 

1 SHOP FLOOR 
; GATEWAY syst 
! Reachable 

( 

1 

> 

t 

1 

am ! 

1 

1 


t 


string 


system description 
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4. 21 BSLSLOQ^EVS'4T - Log a Stjstsm Event in History File 


33L$LQG.£%^ENT 

The Leg Event procedure is s user—cellahit routine to 'arite sn entry 
to the system audit facility. This procedure accepts a formatted 
ASCII text string, from the caller and sends a message to the EVENTJLOG 
process. Depending on specified flagsi the text string may be logged 
in the System Audit file# written to QPER terminals# or both. 

Calling Format; 

QSL^LOG^EVENT ( code# flags# text ) 

Arguments; 

code 

Address of a longword containing a bit mask of event codes for 
this event. The following event codes may be present in any 
combination; 

SSL««_ET SYSTEM 
3SL$M_ST CC?4FIG 
BSL^M.ST iNETWOFK 
3SL««_ET GATEWAY 
BSL^M ET PD 

-bsl$m_et”jser 

3SLSM_ET_DATA 
BSLtM ET APPL 


flags 

Address of a longword containing flags for this event. The 
following flags may be present; 

BSL^M^EF^FILE - Audit event in file 
3SL$M_EF_QPER - Print event on OPER terminals 


- System-related event 

- CcmfiguratioTir event 

- Network event 

- SHOP* FLOOR GATEWAY event 

- Programmable Device event 

- User—related event 

- Data exception event 

- Application-specific event • 
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^pxt 

Address of a descriptor pointing to a character string containing 
an event description. This character string /nay be up to 120 
bytes in lengths and /nay contain any printable characters. If 
multiple lines are desired^ embedded carriage return/1inefeeds 
may be included. 

Return Status: 

2SL«.N0BSL 

A BASEWAY application is not currently running in this UIC group. 
BSLS_N0Rf1AL 

Normal successful completion. 

BSL$_N0P0RT 

The Event Logger message port (EVENT^LOG) does not exist in the 
current application. 
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4.22 BSL«READ_DEVICE_DATA - Read Data from a Programmable Device 
(PDA) - - 


3SL«READ_DEVICE.DATA 

The Read Data procedure allows a caller to perform a logical data 
read from ang address of a programmable device. If a programmable 
device "name is specified# then the current'default *;>rogTammabie device 
name is set to the specified name on completion of this call. 

Calling Format: 

BSLSR£AD_D£VICE_DATA ( Chandlel# Cdevicel# address# count# 

buffer ) . 

Arguments: 

handle 

Optional address of a longword to be used as an internal context 
identifier. A programmer mag choose to keep several handles# 
each with a different context. This parameter must be 
initialised to 0 before being specified for the first time in a 
call# and not modified thereafter. If .this parameter is not 
specified# the sgstem will supplg a default context identifier. 

device 

Optional address of a character string descriptor pointing to the 
text string naming the programmable device. This programmable 
device name string must correspond exactlg to the name of th 
device re<iuested. If this parameter is not specified# the las 
referenced programmable device is used. 

address 

Address of a character string descriptor pointing to the text 
string containing a valid programmable device address. 


a* 


Selected BASEWAY Subroutines 


ll^ *'unt 

Address of a word that contains the amount of data to be read. 
For example/ if the address specified refers to individual bits/ 
or coils# then the count is the number of bits. If the address 
specified refers to a 16—bit word# then the count is the number 
of words. Upon completion of this call# this parameter is 
updated to reflect the amount of data that is actually returned 
in the buffer, 

buffer 

Address of a buffer where the programmable device data should be 
stored. It is up to the caller to insure that this buffer is 
large enough to contain the resulting data. 

Return Status: 

I:.SL$_NCBSL 

A BASEWAY application is not currently running in this UIC group. 
3SL$_N0RMAL 

Service successfully completed. 

^ "L$JMOSYSTEM 

\ 

The programmable device does not have a valid device set 
associated with it. 

B 3L«_N0TSUP FOR TED 

The programmable device does not support this function. 

BSLt PDEVDEFLT 


The caller did not specify a programmable device name and did not 
have a default name set. 

BSL$_NuPDEV 

The programmable device that was specified does not exist. 
BSL^.ATTACHED 

The programmable device is currently allocated to another 
process. 

BSLt BADADDR 
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The address specified in the "ADDRESS” parameter has an illegal 
syntax# or is outside of the range of valid addresses for this 
programmable device. 
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4.23 BSL$READ_DEVICE_STATUS - Read Status Info from a Programmable 
Device (PDA) 


BSL$READ_DEVICE.STATUS 

The Read Status procedure allows a caller to get the status 
rvfcrmation from a programmable device. The format of tbe statu 
uffer is device specific^ and mag contain memory sizes> keg suite 
locationsi etc. 

If a programmable device name is specified/ then the current 
default programmable device name is set to the specified name on 
completion ofthiscall. 

Calling Format: 

BSL$READ_STATlfS ( Chandlel/ Cdevicel/ count/ buffer/ ) 

Ar gument s; 


Optional address of a longword to be used as an internal context 
identifier. A programmer maig choose to keep several handles/ 
each with a different context. This parameter must be 
initialized to 0 before being specified for the first time in a 
call/ and not modified thereafter. If this parameter is not 
specified/ the system will supply a default context identifier. 


Optional address of a character string descriptor pointing to the 
text string naming the programmable device. This programmable 
device name string must correspond exactly to the name of the 
device requested. If this parameter is not specified/ the last 
referenced programmable device is used. 


count 


Address of a word to receive the number of bytes of status 
information read. 
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buff»T 

Address of a buffer where 
should be stored. It 
buffer is large enough to 

Return Status: 

BSL<_NCBSL 

A BASEWAY application is not currently running in this UIC group. 
3SL<_NORMAL 

Service successfully completed. 

3SL<_NCSYSTEM 

The programmable device does not have a valid device set 
associated with it. 

3SL^ J'4CTSUPP0RTED 

The programmable device does not support this function. 
3SL^_PDEVDEFLT 

The caller did not specify a programmable device name» and did 
not have a default name set. 

SSL«_NOPDEV 

The programmable device that was specified does not exist. 
3SLS_ATTACHED 

The programmable device is currently allocated to 
process. 


the programmable device status data 
is up to the caller to insure that this 
contain the resulting data. 


another 
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A 


24 


BSLIiRECEIVE MESSAGE 


Read a Message from a Port 


33L$RECEIVE MESSAGE 


The Receive Message procedure will read an interprocess .message 
from any sender. The calling process must have already established 
ownership of the port (via BSL^CREATE^PORT or BSL$CR£ATE_NAMED_PORT>. 

If no messages are currently queued^ this routine will wait until 
one is received or until the timeout value (if specified) expires. 

Calling Format: 

BSL$.RECEIV£^MESSAGE ( port# Cpointerl# Cbufferl# 

Csrc _port3# Ccodel# Csizej# 

Ctimeoutl ) 


Arguments; 


port 


Address of a longword to containing the port value o? the .port to 
receive the message. 

pointer 

Optional address of a longword to receive the address of the 
message received. This parameter may not be specified if the 
buffer parameter is specified. 

buffer 

Optional address of a buffer to receive the message data. If 
this parameter is specified# then the pointer parameter may not 
be specified. 

source _p ort 

Optional address of a longword to receive the port value for the 
port that sent this message. 
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code 

Optional address of a u/ord to receive the message code 
message. 

size 

Optional address of a uiord to receive the size of this message, 
timeout 

Optional address of a quaduiord containing a VMS system delta time 
to uiait before returning if no messages are outstanding-. 

Return Status; 

BSL^.NOBSL 

A BASEWAY application is not currently running in this UIC group. 
aSL$_NCRMAL 

Service successfully completed. 

SS^^INSFARG 

Not enough arguments mere passed to the routine. 

BSL^^BADMSGSIZS 

The interprocess message size that mas specified is outside of 
the range of 0 to 8000 bytes. 

BSL^JNOBSL 

No BASEWAY application is running. 
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4. 25 BSL$SEND_HSSSA5E - Send a Message to a Port 


BSL^SEND MESSAGE 


The Send Message procedure will send an interprocess message to 
any port in the system. The destination port value must have already 
been found by calling the BSL^ACCESS_PORT procedure. 

The Send Message procedure may be passed either a pointer to a 
.^nessage (created with BSL'$CREATE_MESSAGE or BSL^RECEIVE_MESSAGE) ^ or a 
buffer containing data to be sent. 

Calling Format: 

BSL$SEND_MESSAGE ( Csource^ortl# Cdest_port3/ 

Cpointerl/ Cbufferl/ Ccodel» 

Csizel ) 

Arguments; 

:5 0 urce_port 

Optional address of a iongword 
port that a response should 
requested/ then no source port 

d est_p ort 

Optional address of a Iongword to containing the port value of 
the port that this message is to be sent to. This parameter is 
required unless a pointer to a message that already contains a 
destination port is passed. 

pointer 

Optional address of a Iongword that contains the address of a 
message to be sent. This parameter may not be specified if the 
buffer parameter is specified. 

buffer 

i 

Optional address of a buffer of data to 
parameter is specified/ then the code/ 
parameters are mandatory. 


be sent. If this 
dest^port/ and size 


to containing a port value for a 
be returned to. If no response is 
parameter need be supplied. 
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code 

Optional address of a word that contains the message code for 
this message. 

size 

Optional address of a word containing the size of this message. 
Return. Status: 

BSL^.NOBSL 

A 3ASEWAY application is not currently running in this wIC group. 
SSL-$_NCRMAL 

Service successfully completed. 

SS^.INSFARO 

Wot enough arguments were passed to the routine. 

3SL^_SADf1S«SI2£ 

The interprocess message size that was specified is outside of 
the range of 0 to SCOO bytas. 

i3 3L•^_^40SSL 

No 3ASEWAY application is running. 
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4. 26 BSL$SET DEVICE ATTRIBUTES - 
(PDA) 


Change Current Device Attributes 


BSL$SET_DEVICE_ATTRIBUTES 


The Set Attributes procedure provides a method of setting 
definition and status information for a specified programmable device. 
This call may be used in writing system status utilities. If a 
programmable device name is specified/ then the current default 
programmable device name is set to the specified name on completion of 
th is cal 1. 

Calling .Pormat: 

BSL^SET_DEVICE_ATTRIBUTES ( Chandlel/ Cdevicel* item_iist ) 
Arguments: 
handle 

Optional address o.f a longword to be used as an internal context 
identifier. .A^ programmer may choose to keep several handles/ 
each with a different context. This parameter must be 
initialized to 0 before being specified for the first time in a 
call/ and not modified thereafter. If this parameter is not 
specified/ the system will supply a default context identifier. 

oevice 

Optional address of a character string descriptor pointing to the 
text string naming the programmable device. This programmable 
device name string must correspond exactly to the name of the 
device requested. If this parameter is not specified/ the last 
referenced programmable device is used. 

item_list 

Address of a list of item descriptors that describe specific 
attributes that are requested/ and point to the buffers to 
receive the information. 
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Raturn Status: 

3SL$_NCBSL 

A 3ASEWAY application is not currantly running in this UIC group. 
BSL^^NCRMAL 

Sarvica succassfully complatad. 
aSLS^NOSYSTEM 

Tha prografflfliabla davica doas not hava a valid davica sat 
associatad uiith it. 

BSL^.PDEVDEFLT 

The caller did not specify a programmabla device namai and did 
not hava a default name sat. 

oSL^JmCPDEV 

The prografflfflabla davica that u»as specified doas not exist. 
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Wotes: 

The item descriptors in the item list have the following format: 


31 


16 15 


0 


item code 


buffer length 


buffer address 


return length address 


The format of the item list is described in Section 2.3.3 of the 
VAX/VMS System Services Reference Manual . The item codes for the 
procedure call are described in the table below. 




4-55 






ItSffl I 

! Data I 

1 

1 

Identifier 1 

i Type 1 

! Information Specified 


BSL«K_DA_NAf1E. 

BSL4K_DA_FLA0S 


B SL4K _DA^LQCATION 
3SL«K_DA_DESCRIPT10N 
BSL«K_DA_CONTRACTOR 


string 

valu* 


string 
string 
string 


PragrafflfliabIs dsvice name. 
PrografflflMibIs dsvics status flags. 
Sgmbol ! Msaning 


BSL^N.DAJ^RITEPROT! Writs protectsd 
BSL'$H_DAJDISABL£D ! Dsvics is disabled 
BSLW_DA OFFLINE ' Dsvice is offline 


Location description string 
Dsvics description string 
Contractor description string 
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27 


BSL$SLEEP - Sleep for Specified Time Interval 


BSL$3LEEP 


This procedure will suspend the process execution for the 
specified amount of time. This procedure mag be useful for dgnamic 
terminal displays^ where the program must pause for n seconds between 
refreshes. 

The specified time interval is expected to be a valid ASCII delta 
time.- as specified in the description of the SYS$BINTIM system service 
call. 

Calling Format: 

BSL^SLEEP (ascii_time) 

ATguments: 
ascii_time 

Address of a descriptor pointing to a character string containing 
a valid VAX/VMS delta time. 

Return Status: 

3SL«_N0RMAL 

Service successfully completed. 
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4.29 BSLSSTART^DEVICE - Start a Programmable Device (PDA) 


25LSSTART DEVICE 


The Start Dev.ice procedure provides a means o-f starting a 
programmable device that is currently stopped. This may be necessary 
after douinline loading a new programmable device program# performing 
maintenance# etc. 

Some programmable devices# such as bar code readers# may not 
perform this function. In those cases# an error status return of 
BSLS^NOTSUPPORTED is returned. 

Calling Format: 

BSL$START_DEVICE ( Chandlel# Cdevicel > 

Arguments: 

handle 

Optional address of a longuiord to be used as an internal context 
identifier. A programmer may choose to keep several handles# 
each with a different context. This parameter must be 
initialized to 0 before being specified for the first time in a 
call# and not modified thereafter. If this parameter is not 
specified# the system will supply a default context identifier. 


d evice 


Optional address of a character string descriptor pointing to the 
text string naming the programmable device. This programmable 
device name string must correspond exactly to the name of the 
device rec^uested. If this parameter is not specified# the last 
referenced programmable device is used. 
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Return Status: 

JL$_NCBSL 

A BASEWAY application is not currently running in this UIC group. 
BSL$_NGRMAL 

Service success-f^ul ly completed. 

BSLf.NCSYSTEM 

The programmable device does not have a valid device set 
associated with it. 

3 3L$_N0TSUP P OR TED 

The programmable device does not support this function. 
3SL$_PD£VDEFLT 

The caller did not specify a programmable device name^ and did 
not have a default name set. 

BSL$_NCPDEV 

The p'rogrammab 1 e device that, was specified does not exist. 
^>SL$_NOTSUPPORTED 

The programmable device that was specified does not SLspport this 
operation. 

ESL$_ATTACHED 

The programmable device is currently allocaired to another 
. process. 
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4.29 BSL^STOP^DEVICE - Stop a Prograniinab 1 e Device (PDA) 


3SL*STQP_DEVICE 

The Stop Device procedure pro.vides a means of stopping a 
programmable controller. This mag be necessary for douinline loading a 
nettt programmable device program^ maintenancej etc. 

Some programmable devices* such as bar code readers* may not 
perform this function. In those cases* an error status return of 
SSL$_NOTSUPPORTED is returned. 

Calling Format: 

BSL«STOP_DEVICE ( Chandlel* Cdevicel ). 

Arguments: 


handle 


Optionar^address- of a longuiord to be used as an internal context 
identifier. A programmer may choose to keep several handles* 
each with a different conte.xt. This • parameter must be 
initialized .to 0 before being.specified for the first time in a 
call* and not modified thereafter. If this parameter is not 
specified* bhe system will supply a default context identifier. 

hevice 

Optional address of a character string descriptor pointing to the 
text string naming the programmable device. This programmable 
device name string must correspond exactly to the name of the 
device req,uested. If this parameter is not specified* the last 
referenced programmable device is used. 
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Return Status: 

^ jL*_NOBSL 

A BASEWAY application is not currently running in this UIC group. 
BSLS_NORMAL 

Service successfully completed. 

BSL$_IMOSYSTEM 

The programmable device does not have a valid device set 
associated with it. 

BSL«_NCTSUPPORTED 

The programmable device does not support this function. 
BSL^.PDEVDEFLT 

The caller did not specify a programmable device name and did not 
have a default name set. 

.3SL«_NOPDEV 

The programmable device that was specified does not exist. 
aSL<_NOTSUPPORTED 

The programmable device that was specified does not support this 
operation- 

BSL^_ATTACHED 

The programmable device is currently allocated to another 
process. 
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4.30 BSL«UPLQAD_DEVICE - Upload Logic from a Programmabla Davies 
(PDA) 


BSL«UPLOAD_DEVICE 

Ths Upload Programmabla Davies procadura provides a means of 
loading programmabla device logic from a device into a VAX/VWS file. 

Not all programmable devices support this function. 

Calling Format: 

BSL^UPLOAD_^DEVICE ( Chandlel. Cdevicel, filename ) 

Arguments: 

handle * * 

Optional address of a longuiord to be- used as an internal context 
identifier. A programmer mag choose to keep several handles/ 
each with a different context. This parameter must be 
initialized to 0 before being specified for the first time in a 
call/ and not modified thereafter. If this parameter is not 
specified/ the sgstem will supplg a default context identifier. 

device 

Optional address of a character string descriptor pointing to the 
text string naming the programmable device. This programmable 
device name string must correspond exactly to the name of the 
device requested. If this parameter is not specified/ the last 
referenced programmable device is used. 

filename 

Address of a character string descriptor containing a VAX/VNS 
filename of a fils that is to contain the programmable device 
logic for this device. 
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Return Status; 
jL«_NOBSL 

A BASEWAY application is not currently running in this UIC group. 
3SL*_NORMAL 

Service successfully completed. 

BSL«_NOSYSTEM 

The programmable device does not have a valid device set 
associated with it. 

3 SL$_NOTSUP P OR TED 

The programmable device does not support this function. 
BSL^.PDEVDEFLT 

The caller did not specify a programmable device name and did not 
have a default name set. 

BSL«_NGPDEV 

The programmable device that was specified does not exist. 
_JL$_ATTACHED 

The programmable device is currently allocated to another 
process. 
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4.31 BSL<WRITS_DEVICEJDATA - Writ* Data To a Programmable Dsvica 
<PDA) 


BSL^WRITE.DEVICE_DATA 


Th# Writ# Data proc#dur# allows a call#r to writ# data to any 
addross of a prograimnab 1# d*vic#. If a programmab 1# davic# name is 
specifiedi then th# current default programmable device name is set to 
th# specified name on completion of this call. 

Calling Format: 

BSL<WRITE^DEVICE_DATA ( Chandlel# CdeviceJ/ address^ count# 

buffer ) . 

Arguments; 


handle 

Optional address of a longuiord to be used as an internal context 
identifier. A programmer may choose to keep several handles# 
each with a different context. This parameter must be 
initialized to 0 before being specified for the first time in a 
call# and not modified thereafter. If this parameter is not 
specified# the system will supply a default context identifier. 

device 

Optional address of a' character string descriptor pointing to the 
text string naming the programmable device. This programmable 
device name, string must correspond exactly to the name of the 
device re<iuested. If this parameter is not specified# the last 
referenced programmable device is used. 

address 

Address of a character string descriptor pointing to the text 
string containing a valid programmable device address. 
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count 

Address of a uiord that contains the amount of data to be uiritten. 
For example^ if the address specified refers to individual bits/ 
or coils/ then count is the number of bits to ufrite. If the 
address specified refers to 16-bit words/ then count is the 
number of words to write. 

buffer 

Address of a buffer where the programmable device data is stored. 
It is up to the caller to insure that this buffer contains enough 
data to fulfill the write request. 

Return Status: 

BSL$_NOBSL 

A SASEWAY application is not currently running in this UIC group. 
i3SLS_NCRMAL 

Service successfully completed. 

3SL$_NOSYSTEM 

The programmable device does not have a valid' device set 
associated with it. 

BSL«_NOTSUPPORTED 

The programmable device does not support this function. 
BSL$_PDEVDEFLT 

The caller did not specify a programmable device name and did not 
have a default name set. 

BSL«_NOPDEV ^ 

The programmable device that was specified does not exist. 
BSL$_ATTACHED 

The programmable device is currently allocated to another 
process. 

BSL«_BADADDR 

The address specified in the "ADDRESS” parameter has an illegal 
syntax/ or is outside of the range of valid addresses for this 
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prografliflwb 1 a davica. 
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4. 32 BSL$WRITE^VEBIFY^DEVICE^DATA • Writ® Oat® To ® Programfnab 1 e 

Uevice and Verify (PDA) 


3SL*WRITE^VEPIFY_D£VICE_DATA 


The Write Verify Data procedure allows a caller to perform write 
data to any address of a programmable device. If a programmable 
device name is specified/ then the current default programmable device 
name is set to the specified name on completion of this call. 

Calling Format: 

BSL$WRITE_VERIFY_DATA ( Chandlel/ Cdevicel/ address/ 

count/ buffer ) 

Arguments: 

handle 

Optional address of a longword to be used as an internal context 
identifier. A programmer may choose to keep several handles/ 
each with a different context. This parameter must, be 

initialized to 0 before being specified for the first time in‘a 

call/ and not modified thereafter. If this parameter is not 
specified/ the system will supply a default context identifier. 

device 

Optional address of a’ character string descripto.r pointing to the 
text string naming the programmable device. This programmable 
device name string must correspond exactly to the name of the 

device requested. If this parameter is not specified/ the last 

referenced programmable device is used. 

address 

Address of a character string descriptor pointing to the text 
string containing a valid programmable device address. 
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count 


Address of a (tford that contains the amount of data to be written. 
For example^ if the address specified refers to individual bits/ 
or coils/ then count is the number of bits to write. If the 
address specified refers to 16-bit uiords/ then count is the 
number of uiords to write. 


buffer 


Address of a buffer where the programmable device data is stored. 
It is up to the caller to insure that this buffer contains enough 
data to fulfill the write request. 

••return Status: 

BSL«_NOBSL 

A BASEWAY application is not currently running in this UIC group. 
BSL% NORMAL 


Service successfully completed. 

BSL^.NOSYSTEM 

The programmable device does not have a valid device set 
associated with it. 

BSL$_NOTSLPFCRTED 

The programmable device does not support this function. 

33L$ PDEVDEFLT 



The caller did not specify a programmable device name and did not 
have a default name set. 


3SL« NCPDE'-^ 


ine programmable device that was specified does not e.tist. 

5 SL‘S_ATT.ACHED 

The programmable device is currently allocated to another 
process. 

3SL-$ BADADDR 


The address specified in the "ADDRESS'* parameter has an illegal 
syntax/ or is outside of the range of valid addresses for this 
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prograriifliable device. 
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tS 


APPENDIX A 


BASEWAY SUBROUTINE CALLS 


A. 1 BASEWAY Language-Independent Notation 


BASEWAY routines are invoked according to rules specified in the 
VAX Procedure Calling and Condition Handling Standard (Appendix C of 
^^AX Run-Time Library Reference Manual) . The complete notation for 
escribing VAX calls is documented in Appendix C of the VAX Guide to 
reatir>q Modu 1 ar Libraru Procedures . 


BASEWAY routines can be invoked as subroutines or as functions: 



As a subroutine: 

CALL BSL^xxx (parameter!/parameter2/ . . . ) 

As a function: 

VMS^stat. wlc. V * BSLSxxx (parameter!# parameter2/. . . ) 


The access type/ data type# passing mechanism# and parameter form 
are described in the fo!lou»ing prescribed order: 

<Iparameter-naffle>.-Caccess typeXdata type>. <passing mech'ani smXparameter form 
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A.2 Procedure Parameter Notation for SASEWAY Calls 


3A3EWAY uses a subset of the VAX procedure parameter notation. 
The following table explains the notation used for access tgpe^ data 
type^ passing mechanism# and parameter form. 


Notation 

Caccess type> 

Comments 



m 

Modify access 

Parameters for both input 
output 

and 


r 

Read-only access 

Parameters for input 



Ul 

Write-only access 

Parameters for output 



Notation 

<data type> 




a 

Virtual address 




1 

Longword integer (signed) 



Ic 

Longword return status 




q 

Cuadword integer (unsigned) 


*4 

Character-coded text s 

tring 



V 

Aligned bit string 




til 

Word integer (signed) 




X 

Any data type 




Notation 

<pasaing mechanism^ 

Comments 



d 

By descriptor 

BASEWAY passing mechanism for 
character strings and integer 



arrays 

r By reference BASEWAY passing mechanism for 

integers 
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tation 


<paraflieter form> 


a Array reference or descriptor 

xl Fixed-length or dynamic 

string descriptor 
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Procffdurs Parameter Notation 

BSLaACCESS.OEVICc ( Chandle. ma. rCname. rt. dx 13 ) 

handle context identifier 

name programmable device name 

Places the current context pointer to a specific 
programmable devicSf and returns the access status. 


BSL^CCESS^PORT < port. wl. r# Csgstem. rt. dxl3» name. rt. dxl* ) 

port port value 

sgstem application# device set or gateway name 

name port name 

Returns the port value for a particular named 
port currently active on an application# device 
set# or gateway. 

BSLaALLOCATE^DEVICE < Chand 1 e. ma. r3# Cname. rt. dx 13# Cf lags. rv. r3 ) 

handle context identifier 

name programmable device name 

flags allocation flags 

Narks a programmable device for exclusive use by the 
calling process. Causes any automatic data gathering 
(polling) to cease. Usually used when performing a 
diagnostic function or when downline loading a 
programmable device. 


BSLaCONPARE^DEVICE ( Chand le. ma. r 3# Cname. rt. d x 1 3# file. rt. dxl ) 

handle context identifier 

name programmable device name 

file VAX/VMS file name 

Compares two programmable device logic files and 

returns a summary of differences. 
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Procedure Parameter Notation 


BSL^COMPILE_DEVICE_ADDRESS ( Chand le. ma. r 3# Cname. rt. d x 13i address, rt. d x 1/ 

compi led. rt. dxl ) 


handle 

name 

address 
compiled 


context identifier 
programmable device name 
address in programmable device 
precompiled address string 


Parses an address for this programmable device# and 
returns the precompiled address string. This .string 
is nonprintable# but may be used in other 
calls in place of the address string. 




5SLSCRE/4TE MESSAGE ( 


pointer, wa. r# Csize. rw. rl# Ccode. rw. r3# 
Cdestjort. rl. r3# Csource_port. rl. r3 ) 


pointer 

size 

code 

destj ort 
source _port 


address of message 

size of data buffer in bytes 

message code 

port value 

port value 


‘it 


Allocates space for an interprocess message# and 
returns a pointer to the data area of this message 

3L$CR5ATE_NAMED_P0RT ( port. u/1. r# name. rt. dxl# Csi ze. rui. r3# 

Cqueued. ru>. r3# Cid.rui. r3# ) 


port 

name 

size 

queued 

id 


port value 

name given to this port 
maximum buffer that can be received 
maximum number of messages .that 
can be queued to this port 
identification number (64-127) 


Allocates a permanent message port# associates 
the given name with it# and assigns it to the 
calling process. 
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Procedure Parameter Notation 


BSLSCPSATE^PORT ( port. uil. r< Csize. rw. r 1* Cqueued. rw. rl/ ) 

port port value 

size maximufli buffer that can be received 

queued maxifliuiii number of messages that 

can be queued to this port 

Allocates a temporary message port and assigns 
it to the calling process. 


BSLSCVT^NX^DX ( src^desc. rx. dxl# dest__desc.wx.dxl/ ds3t__l6n. ww. r ) 

src__desc . address of message descriptor 

dest^desc address of VAX data descriptor 

dest_.len size of resulting value 

Converts data described by src^descriptor into 
data type described by dest_desc/ and copies th 
resulting value to the space described by dast_ 

SSL$DATA^TYPE ( Chandla.ma.rl/ Cname.rt.dxll/ ad d7^« s. rt. d x 1/ type ) 

handle context identifier 

name programmable device name 

address starting memory location address 

type data type at this address 

a 

Parses an address for this programmable device/ and 
. returns the type code for the data at this address: 

BSLtK_DT_BIT - 1-bit or coil address 
3SL^K_DT_BYTE - Byte data at this address 
BSL^K^DT^WORD - 16-bit word data 
BSL^K__DT^LCNO - 32-bit long word data 


BSLSDEACCESS.DE'yiCE < Chand i e. ma. r 1 ) 

handle context identifier 

Clears any programmable device context previously 
associated with this handle. 
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Procedure Parameter Notation 



iiSL^OEALLOCATE DEVICE ( Chendle. ma. r]/ Cname. rt. dx 13 ) 


handle context identif'ier 

name programmable device name 

Frees a previously allocated programmable device^ and 
causes normal data'-gathering functions to resume if 
possible. 


BSLaDELETE^MESSACE ( pointer, ma. r ) 


pointer address of message 

Releases space occupied by this message. 


BSL^DELETE.PORT ( port. ml. r ) 

port port value 


Releases a message port that was assigned to the 
calling process. 



^L*DQWNLOAD_DEVICE ( Chandle.ma.r3/ Cname*. rt. dx 13/ file. rt. dxl ) 

handle context identifier 

name programmable device name 

file VAX/VMS file name 


Loads a VAX/VMS file containing device logic into a 
programmable device. 


c 
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ProcBdurB Parameter Notation 


SSLISOET^DATA^INFO < Cid. r 1. r 1 Cname. rt. d x 13# item^list. ra. r) 

id data identifier code 

name data point name 

item^list pointer to array of item descriptors 

Returns selected information about the data point to 
the calling program. 


3SL^ET_,DEVICE^ATTRIBUTES < Chandle. ma. r3# Cname, rt. dx 13> item^l.ist. ra. r ) 

handle context identifier 

name programmable device name 

item^list pointer to array of item descriptors 

Returns selected generic attributes of the programmable 
device to the caller. 

BSLSCET^SESSION^INrO ( i tem^l i st. ra. r ) 

item^list pointer to array of item descriptors 




,p / 


^ 5 

4 




Returns information about the current terminal 
session to the caller. 
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Procedure Parameter Notation 


BSL$C£T_SYSTEM^INFO < Cid.rui.rl/ Cname.rt.dxll/ item^list. ra. r ) 


id system internal identifier 

name application/ device set or gateway name 

item^list pointer to array of item descriptors 

Returns information about an application/ device 
set/ or gateway to the caller. 

2SL$LDC_cVENT < code. rv. r/ f lag. rv. r/ text. rt. dxl ) 

code event type mask 

flag event flag mask 

text text string to log 

Enters a user-defined text string in the System 
Audit file. 


BSL$READ_DEVICE_DATA ( Chand le. ma. r 1/ Cname.rt.dxll/ Caddress. rt. 

count, rw. r/ buffer, ra. r ) 



hand 1e 
name 
address 
count 

buffer 


context identifier 
programmable devi.ce name 
starting memory location address 
number of pieces of data to read/ 
returns number actually read, 
pointer to a buffer to receive the 
data read 


dxl 


1 / 


Reads a buffer of data from the address in the device 
specified. Data will be returned in the same format 
as contained in the programmable device. 


B3LtREAD_DEVICE_STATUS < Chand le. ma. rl/ Cname.rt.dxll/ count, ww-. r/ 

buffer, ra. t, ) 

handle context identifier 

name programmable device name 

count number of bytes of data read 

buffer pointer to a buffer to receive data 

Reads a buffer of programmable device specific status 
information. 




A-9 



BASEWAY Subroutine Calls 



3SL$RECEIVE_liESSACE ( port. rl. r# Cpointer. ra. r3/ Cbuffer. rx. r3i 

Csrcjort. wl. r3/ Ccode. wui. rl# C si ze. uiw. r 3/. 
Ctiflieout. rq. r3 > 


port 

pointer 

buffer 

src^ort 

code 

size 

timeout 


port value 
address of message 
data buffer 
port value 
message code 

size of data buffer in bgtas 
VAX/VHS binary delta time 


Reads an interprocess message sent to the specified 
port. If no messages are pending# will wait until 
timeout value expires. tlessage may be referred to by 
pointer or data buffer. 


BSL^SEND^MESSAGE ( Csrcjort. rl. r3# Cdestjort. rl. r3# Cpointer# ra. r3# 

Cbuffer. rx. r3# Ccode. rw. r3# Csize. rw. r3 ) 


src jort 

dest jort 

pointer 

buffer 

code 

size 


port value 
port value 
address of message 
data buffer 
message* code 

size of data buffer in bytes 



Sends an interprocess message to the specified port. 
Message may be referred to by pointer or data buffer. 


13SL$SET_DEVICE_ATTRIBUTE3 ( 

handle 

name 

item_I ist 

Allows the 
such as the 


Chand 1 e. ma. r3# Cname. 

cont8.xt identifier 
programmable device 
pointer to array of 

calling process to set 
station number# of a 


rt. dxl3# item list. ra. r ) 


name 

item descriptors 

a generic attribute# 
programmab1e device. 
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Procedure Parameter Notation 

SSLiSLEEP < string, rt. dxl > 

string VAX/VMS time formatted string 

Causes the calling process to enter a LEF state until 
the specified time. 


BSL^START DEVICE ( Chand le. ma. rl# Cname, rt. d x 13 ) 



handle context identifier 

name programmable device name 



Starts the programmable device if the device was 
previously halted. 


5SL$ST0P_DEVICE < Chandle.ma.r3/ Cname. rt. dx 13 ) 


handle context identifier 

name programmable device name 

Stops the programmable device if the device was 
previously running. 


"L^UPLOAD DEVICE ( Chand 1 e. ma. r3/ Cname. rt. dx 1 3/ file. rt. dxl ) 


hand 1 

name 

file 


e 


context identifier 
programmable device name 
VAX/VMS file name 


Uploads logic from a programmable device into 
a VAX/VMS file. 


BSL*WRITE_DEVICE_DATA ( Chand 1 e. ma. r3/ Cname. rt. dx 1 3/ Caddress. rt. 

count, rw. t> buffer, ra. r ) 



handle 
name 
ad dres s 
count 
buffer 


context identifier 
programmable device name 
starting memory location address 
number of pieces of data to write 
pointer to a buffer containing data 


dxl3/ 


Writes a buffer of data to the programmable device 
starting at the address specified. Data will be 
written in the same format as it appears in the 
caller 's buffer. 
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Procedure Parameter Notation 



BSL^WRI7E_VERIFY_DEVICE_DATA ( Chandle. ma. rl, Cname. rt. dx 13. 

Caddress. rt. dX13* count, rw. r* buf-Fer. ra. r ) 




context identifier 
programmable device name 
starting memory location address 
number of^ pieces of data to uirite 
pointer to a buffer containing data 

Writes a buffer of data to the programmable device 
starting at the address specified and verifies that 
it was written correctly. Data will be written in 
the same format as it appears in the caller's buffer. 


handle 

name 

address 

count 

buffer 
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APPENDIX B 
SHOP FLOOR GATEWAY 


SHOP FLOOR GATEWAY allows a PDP—11 procsssor to act as a 
front—end processor for communicating with shop floor programmable 
devices. A manufacturing application built on BASEWAY can use SHOP 
FLOOR GATEWAY to read and write to programmable devices on the shop 
floor. 

The GATEWAY provides the actual communications interface to shop 
floor devices; BASEWAY provides application program communications 
and control functions. The GATEWAY offloads the automatic 
oata-gathering and qualification processing from the VAX processor. 
All necessary protocol and data conversion are also performed by the 
GATEWAY. 

GATEWAY software is downline loaded into a PDP-11 processor at 
^ixartup using the VAX DECnet downline system load facility. 

Information pertinent to adding new device support is given in 
Appendix 0 of this manual. 


D. 1 Features 


The GATEWAY supports the BASEWAY programmable device access 
routines. These allow application programs to interact with shop 
rioor devices in a variety of ways: 

o Generic Access allows an application program to perform 
primitive functions through device-independent routines. 
These functions include reading and writing into device 
addresses^ starting and stopping devices# and getting device 
attributes. 

o Polled Access permits the GATEWAY to sample device data 
periodically and send a message to an application program 
when data changes. 
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B.2 Components 


The Network Interface component allows the GATEWAY to participate 
in the BASEWAY messaging architecture. 

The Event Processor performs data conversions to convert 
programmable device data, into a format easily useable by an 
application program. 

The Generic Server responds to generic device access and helps 
provide a generic interface to programmable controllers. 

The Polled Server scans the programmable device point definitions 
and periodically collects data from programmable devices. 


3. 3 Functions 


The SFG performs the following functions: 

0 receives device—specific commands* acts upon them* and 
returns data and/or status. 

0 polls programmable devices as specified in a polling 
database* performs certain preprocessing manipulation of the 
polled data* and transmits the polled data to BASEWAY. 

0 detects PD communication faults and notifies BASEWAY of their 
occurrence. 

0 performs self-diagnostic checks as well as diagnostic checks- 
of programmable devices. 

0 self—initializes following a bootstrap operation and runs 
without direct operator intervention. 

0 accepts polling configuration data from BASEWAY on startup 
and keeps a copy of the “last polled" data in the palling 
database. 
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3.4 Device Access Supported 


Several different methods of communicating with a programmable 
device are supported. 


B. 4. 1 Direct Access 


Direct access allows an application program anywhere in the 
network to perform logical "GIO" functions directly to the 
communications port. (NOTE: “QIO** functions are the RSX-llS 
executive directives for performing i/o to a device driver or device 
interface software. This permits application programs to perform 
device-specific functions that are not supported by other access 
methods. 


B. 4. 2 Generic Access 


Generic access allows applications programs to read registers/ 
write status bits/ and perform other control functions. No knowledge 
oftheprotocolsisrequired. 


5 Equipment Access 

Equipment access allows the automatic gathering of predefined 
data. This data is collected in either a polled or unpolled manner. 
Gnce collected/ the data is relayed to an application program. 


3.6 Types of Data Capable of Being Polled 


0 Coils/ or.bits 

0 Registers/ containing 

- bits 

- words 

- BCD 

- ASCII strings 
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DEVICE INTERFACE MODULES (DIMs) 


C.1 Overview 


Device Interface Modules (DIMs) contain the device-specific 
routines to handle the actual programmable device communications. The 
four main routines in a DIM and the tasks which call them are 
summarized in the table below: 


I .ROUTINE { CALLED BY i 

! i/o cancellation I DIRSRV, GENSRV, POLSRV I 

I access / i/o I DIRSRV, OENSRV, POLSRV I 

{initialization ! I 

+- 1 -+ 

! direct access request! DIRSRV I 

I processing ! I 


—h 


! generic access 
I request processing 

H —-——-— —- 


I GENSRV, POLSRV 


The servers call the desired DIM routines bg invoking the macro 
DIMDO$. This macro searches the Device Vector Table> D$VECT for the 
DIM entry table address associated with the interface device type. 
The server then uses the address contained in that DIM entry table at 
the offset of the routine. The DIM sets up and executes the necessary 
functions required to perform the desired request. 

The PD access servers and the DIMs pass information through two 


data structures: 
Block (LCB). The 
interface lines, 
and from the DIM. 
later section. 


the Line Access Block (LAB) and the Line Control 
LABs are used to maintain information related to the 
The LCBs contain the context of service request to 
These structures are described in more detail in a 
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Each PD server task has an active LAB for each defined PD 
interface. When service requests are received the LCBs are queued to 
the corresponding LAB. The LCBs are dequeued as the requests are 
processed. The following figures illustrate this interaction between 
the servers and the DIMs. 



Device Interface Modules 


SERVER 


DIM 


! Receive a service ! 
! request ! 


V 

! Set up the LCB of 
I the request and 
! find and queue the 
I LCB to the LAB 


V 


I Call the DIM using! 
I DIMDO< if this is I 
! the only LCB on ! 
I the LABs queue ! 


{ \ -+ 

\ 

Use information 1 


from the LAB and ! 


LCB to set up and ! 


perform a QIO with! 

/ 

an AST. RETURN 1 


( / I an ns <. nE:;.ivnn i 

Y / H-+ 


! Exit AST. Wait I 
! for next request 1 

+-+ continued 

next page 

Figure lOA. PD Access Server - DIM Interaction 
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SERVER 


DIM 


server's ^PDDON / 
>■ - - —- . 1 . ■ 

! Forniat and send a ' 
I response message I 

Y 


! AST completes. Set 
' up parameters and 
/! call to «PDDON 

.. ■I. -— «■ 


I Dequeue the LCD ! 
! from the LAB queue! 



Call the DIM using 
DIMOOdi and next 
LCB if there are 
still LCBs on the! 
LABs queue ! 


\ H 
\ 

Use information 1 


from the LAB and 1 


LCB to set up and 1 


perform a GIO uiith! 

/ 

an AST. RETURN ! 




! Exit AST. Done uiith! 
1 service. I 


Figure lOB. PD Access Server - DIM Interaction 

< Continued) 
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C.2 DIM - PD Access Server Data Structures 


The PD Access Servers use tuio data structures to pass information 
to and from the DIMs. They are the Line Access Block (LAB) and the 
Line Control Block (LCB). These structures are passed to the DIMs in 
the following manner. The address of the LCB is passed to the DIM in 
R5i the address of the LAB associated with this LCB is contained in 
that LCD. 

In the description of the data structure layouts that follow/ the 
locatiops in the data structure are referred to by their symbolic 
offsets as defined in the corresponding macro as shown. Then* the 
usage of the location is given below using a special notation: 

symbol <n) : ff Description... 

symbol - symbolic offset from macro definition 



n length of field in 

bytes 



ff - data format/ *'BU" 

- binary unsigned 

value 


"BS" 

- binary (signed) 

value 


"BM” 

- bit mapped ( i. e. 

flags) 


"C" 

- coded 



*'A“ 

- ASCII 
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C. 2. 1 Line Access Slocks (LABs) 


The Line Access Slocks contain PD interface line-rei 
information required by the Access servers and the DIMs. Most of 
information is copied from the Inter-face Definition - Slocks (IBs) in 
VDR as the servers are started. The LAB offsets are defined in the 
macro LAB4 of MACROLIB and defined as follows: 


4 

4 

L. LUN 

1 

1 

1 

t 

L. FLAG 

1 

1 

1 L. LCBH i 

1 

a 

L. LCBT 

1 

1 


L. IBVP 


L. DEV 


f 

L. UNIT 


f 

1 

L. POLL I unused 

t 

1 

1 

1 

L. NREQ 

t 

1 

1 

1 

L. NERR 

1 

1 

1 

i 

L. TERR 

a 

1 

t 

t 

-H— — 

L. ERRL 

t 

1 


L. LUN(2) SU The logical unit assigned to this line 

by the server 

L. PLA<S<2) :• BM The status flag for the LAS's usage 

Bit 0 - LF. USD This block is used 
for an interface line 
Bit 1 - LF. QNL This block is 
associated with an 
accessible line/port 
Bit 2 - LF.PND An operation is 

pending on this line < i. e. .• 
there is an LCB queued to it) 
Bit 3 - LF. POL A polling cycle is in 
progress for this operation 
Bit 4 - LF. DED Dead poll flag 

L. LCBH<2) BU The queue head pointer of the pending 

LCB list 
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L. LCBT<2) 

W" IB VP (2) 

L. DEV(2) 
L. UNIT<2) 
L. POLL < 1) 
Unused(1) 
L. NREQ<4) 

L. NERR<4) 

L. TERR (4) 

L. ERRL<4) 


BU The queue tail pointer of the pending 
LCB list 

BU The virtual pointer of the associated 
IB in VDR 

A The device name of this port 

BU The device unit number of this port 

BU The poll counter# poll if 0 

BS The count of requests serviced for 
this port 

BS The count of service error for this 
port 

BS The count of service timeout error 
for this port 

BU The lOSB of the last failed GIO 






Dsvice Interfaca Modulas 


C. 2. 2 Line Control Blocks (LCBs) 


The context o-P the access service request is passed to the DIMs 
through the Line Control Blocks. The Line Access Blocks are defined 
in the macro LCBdi of the library HACROLIB and defined as follows: 



-ii-—' -irr»nm-n mi 

1 

1 

1 

1 

C. IQSB 

c 

> 

\ 


I C. LCBP I 

-- -— - - -- h 

! C. LAB ! 


1 

1 

C. PBVP 

1 

1 

1 

C. SBVP 

1 

^m miM mm mmm 

9 

1 

C. DBVP 

f 

1 

r 

1 

C. DB05 

1 

f 

1 

C. FLAC 

f 

t 

1 C. STN 1 

{ C. SLAV 


C. EXTN 
(3 words) 


1 C. MNFR 


1 

f 

C. MQDL 

t 

1 

. . 

r» 

-< 

! 

1 

1 -. 

1 

t 

C. SAVE 



C16 words) 

I 

t 

1 

1 

C. SRVS 

t 

1 

H———. 


—— h 

I 

f 

C. MADR 

f 

1 

1 

1 

C. MPNT 

t 

1 

1 C. MLEN 1 
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A DIM has four functions: 
o cancellation / deaccess 
o initialization 
0 direct access 
o generic access 


All four routines need to return the follouiing to the requesting 
server: 


completion service status code* offset C. SRVS of the LCD. 
The following status codes are defined: 


ss. sue s 

SE. CAN » 
SE. TMO » 
SE. FNR = 
SE. OFL * 
SE. PRG a 
SE. I NT * 
SE. DEV =* 
SE. RSC » 
SE. VFY » 
SE. CNT = 


SE. ADR = 


service completed successfully 
access service was cancelled 
access service timed out 
function rejected by service 
interface was^ offline 
protocol error 
interface error 
invalid device type error 
resource access error 
verification error 

invalid count (biti byte; or word) 
fer specific device »3IO 
address was invalid as determined by 
the DIM or device error return 


R5 remains pointing to the current Line Control Block 

R1 contains the number of bytes returned from the DIM 
comp 1etion. 

The status and byte count•returned from the completed GIO 
needs to be placed in the C. lOSB and C. IOSB+2 offset of the 
LCB. 


The four routines also receive and return operation-spscific 
information (described in Sections B. 4. 1—B. 4. 4 below) from the 
requesting server. These fields are offsets of the LCB data structure 
and in the service specific message buffer. They are described in 
detail under the appropriate DIM routine. 

The last three words of the Line Control Block contain the 
information required to access the service request message. All 
mailbox messages are contained in a common region GLBCGM. (See the 
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.I0SB(4) 

.LCBP<2) 

. LAB(2) 

. FLAG<2) 

. PBVP(2) 

. SBVP<2) 

, DBVP(2) 

. STN<2) 

. SLAV(2} 

. EXTN<16) 
. MNFR<2) 

. M0DL(2) 

. TRYC2) 

C. SAVE<32) 

C. SRVS<2) 

C MADR<2) 


C. MPNT<2) 


C. ML£N(2) 


; BU i/o status block 

BU The pointer to the next LCB of a 
LAB request queue 

BU The pointer to the LAB that this 
LCB is to service 
BM The block usage and status flag 
BU The programmable device block VP 
BU The polling set block VP 
: BU The data definition block VP 
: BU The device station address 
: BU The device slave station address 
: BU The extended address 
BU The manufacturer code 
BU The model code 

: BU The number of attempts to try the 
service before rejecting 
BU A user area to save i/o context for 
ASTs 

BU The generic service status code of 
the result of the service 
; BU The mapped address of the message buffer. 

This uiord is used for storing the 
address of the message buffer. This 
buffer corresponds.to the mapping 
parameters in C. BPNT and C. BLEN. This 
address i*s only valid if the buffer is 
currently mapped. 

: BS The block offset into the global buffer 

region of the message buffer. This is 
one of the parameters required to map 
the message buffer. 

BS The length of the message buffer in 32 word 
blocks. This is one of the parmeters 
required to map the mailbox message buffer. 


The actual format of the request messages depend on the server 
and the request. 


C. 3 DIM-Server Protocol and Considerations 


The device access servers DIRSRVi GENSRV, and POLSRV pass 
information to and receive information, from the DIMs through two data 
structures. These data structures are the Line Control Block (LCB) 
and the Line Access Block (LAB) described above. Before a server 
enters the device interface module^ it places the address of the LCB 
in R5. The address of the LAB associated with the request is stored 
at location C. LAB(R5). 
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C. 3. 1 Initialization Procedure Considerations 


This module performs any operations that may be necessary to 
initialize access to a device's interface software. An initialization 
request is performed by the servers before any device requests are 
acepted. These routines should be synchronous and use GIOWs inhere 
necessary. 

The LCB associated with this request does not have a global 
message buffer associated with it. The initialization routine should 
pass the following to the routine UPDDON: 

1. R5 * address of the LCB passed to the DIM with the following 
fields containing: 

o C. SRVS a Generic status of the initialization routine 

0 C.lOSB » I/O status block of any QIO function that may 
have been performed. 


R1 3 0 since there is no data to be returned. 


C. 3. 2 Cancellation Procedure Considerations 


The cancellation service routine allows the access servers to 
deaccess the communication software of the initialized interfaces. 
This is necessary if the servers need to update or reconfigure the 
device network. The servers perform a IQ. KILL QIO function on each 
interface prior to calling the associated DIM cancellation service 
routine. The cancellation routine perorms all device specific 
operations required to deacess the interface. 

As with the initialization routine^ the LCB associated with the 
request does not have a message buffer. The cancellation routine 
should pass the following to the routine $PDDON: 

1. P5 » address of the LCB passed to the DIM with the following 
fields containing: 

0 C. SRVS =* Generic status of the initialization routine 

o C. IOS3 * I/O status block of any QIO function that may 
have been performed or filled wi t h zeros. 
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RSX—11M/M~PLUS executive Re-Perence Manual for more information on 
virtual addressing and mapping) Inorder to address a message it must 
be first be mapped. The message buffer associated with the LCB can be 
mapped using the block offset pointer C. MPNT(R5) and the block length 
of the buffer C. ML£N(R5). It may be assumed that the servers have 
established the mapping context of the message b-uffer prior to calling 
the DIM. 

The mapping context of the message buffer is not guaranteed when 
entering a completion AST. The SFG macro MPLCB4 may be used to map 
the message buffer and store the resulting address in the word 
C. MADR<R5). The macro ASDIM* envokes MPLCB^ helping to reestablish 
the context of the req,uest. 

To prevent the loss of the message context and possible 
corruption of the Shop Floor Gateway system/ DIM code should not 
modify the offsets C. MPNT and C. MLEN. 

From time to time it may be necessary to allocate a buffer from 
memory. The servers are installed with extra free memory in their 
task partitions. Use the free memory head pointer F-SRErlD and the RSX 
System library routines SRGCB and -SRLCB to allocate and deallocate the 
required buffers. Since the number of bytes returned by aRQCB may not 
mat-ch what was requested/ be sure to store the address and actual 
length returned and use them to dealocate the buffer with -SRLCB. 
These value can be stored in offsets to C. SAVE in the current LCD. 
Refer to lAS/RSK—l 1 Sus.tem Libraru Routines Reference ManuaI for 
details on these routines. 
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C.3.3 Direct Access Service Processing Considerations 


Direct access routines provide applications the ability to 
perform remote QIOs to programmab1e devices. The direct access 
message contains the information required by the DIM to set up the GIG 
directly. This message is described beloui. 

QIOs performed by a direct access DIM routine should be 
asynchronous. That is# set up and issue the QIC specifying the next 
step in the logic as the AST entry point parameter and return. idhen 
the i/o completes continue processing the request as an AST routine. 


M. DATA 


> 

1 

R. D5EQ 

> 

1 

1 

1 

R. DDEV 

1 

1 

-H— 

1 

1 

R. DUNT 

1 

1 

1 

R. DDSW 

t 

1 




1 

1 

R- DIOS 

I 

1 

f 

1 

R. DIOC 

1 

1 

•H—— 


- h 

1 

1 

R. DFNC 

1 

1 

1 

1 

R. DPRM 


1 

(-6 Words) 

t 

1 



1 

I 

1 

1 

R. DDAT 

1 

1 

f 

(Optional^ 256 bytes 

max) ! 

t 

t 


R. DSEG(2) 

R. DDEV<2) 

R. DUNT(2) 

R.DDSW<2) 

R. DI0S<2) 

R. DiaC<2) 

R. DFNC(2) 

R. DPRM<12) 

R. DDAT<256> 


BU The sequence number of the request 
BU The interface name 
BU The interface unit number 
BU The directive status word of the GIG 
BU The i/o Status return of the GIG 
BU The i/o Byte count 
BU The i/o function code for the GIG 
BU The 6-word device-specific GIG 
parameters 

BU The PD data buffer 
Direct Access Service Message Format 
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0 since there is no data to be returned. 
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Set up LCB/ request message buffer and registers and 
$PDDON to complete the request 

Exit the AST routine. 


call 


C-io 
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The direct access service message contains the follouiing fields 
for the DIM'S use; 

- R. DFNC« the QIO function to be performed 

- R. DPRMi an array of six words providing the necessary 
device—spec ific QIO parameter requirements for the DIM to 
issue a GIO to that device. 


The following offsets in the direct access format Line Control 
]31ock need to be updated. 

- C. SRVS# DIM completion service status code 

- R. DDSWf the directive status word of the QIO invocation 

- R. DIOS* the status return of the QIO 

- R. DIOC* byte count returned from the QIO completion 

- R. DDAT/ buffer area holding data from a read QIO function 


The following steps may be used as a guide to coding the direct 
ervice routines; 

The logic flow of a typical direct service routine would be as 
follows; 


Validate function code and evaluate device dependent 
parameters in the R. DPRM offset of the LCB. Some parameters 
may need to be provided at the DIM level. These would 
include addresses of data buffers* DIM overwritten timeouts* 
or size parameters. 

Format and invoke the QIO specifying a completion AST 
routine. 

Test the directive status word of the QIO invocation* if 
successful* return to server* if unsuccessful* set the 
offsets necessary for the calling server* CALL <PDDON* and 
return to the server. 

Restore stack* set R5 as LCB pointer (AST parameter)* and 
remap the message buffer. 

Evaluate the i/o status block of the resulting QIO function, 
and deterimine the corresponding generic status value. Retry 
if the function if was a ti.meout. 
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BU Sit off set field (device specific in its 
usage and interpretation 
BU The data count 
BU The PD data buffer 

Generic Access Service Message Format 


R. GSEQ is not currently beeing used and should not be modified by 
the DIM. R. GDip is used by the server to determine which LAB it 
should queue the request tO/ it too should not be modified by the DIM. 
R. GSTS is the generic completion code of the request. The sever's 
iPDDON copies the value that the DIM places in C.SRVS(R5) in R. QDID of 
the message. 

The values in the fields M. CODE^ R. GCNT and buffers R. GADR* 
R. GDAT are used by the DIM to perform the function. The value of 
M.CODE defines the function to be performed. Valid codes are defined 
in the macro MXCOD-i of MACROLJB. The are: 

MG.RED Perform generic read from the device 
MG. WRT Perform generic write to the device 

MG. WTV Perform generic write to the device and verify 

“’'^'perform read of device status 
Start the device 
Stop the device 
Log on to the device 
Log off the device 

Start the operation of uploading of device 
.memory 

End the operation of uploading of device memory 

Start the operation of down loading of device 

End the operation of down loading of device 
memory 

If the function requires an address in the device^ it is passed 
in the buffer starting at offset R. GADR. The contents of this buffer 
is an internal BASEWAY address^ that iSi it was created by the BASEWAY 
device address translator. Both the translator and DIM code must 
interperate this buffer in the same way. 

The R. GATY offset in the message determines the type of address 
contained in the buffer. Current address types are bit. physical, and 
logical. R. GBOF is used for device specific bit offset determination. 

The R.GCNT field contains the number of data types to operate on. 
IP R. GADR contains a bit address. .R. GCNT is interms of bits. If 
R.GADR is a word register address. R. GCNT is the number of words to 

c ■ 

•C~1S 


nw. 

MG. SRD 
MG. SPD 
MG. LON 
MG. LOF 
MG. SUL 


MG. EUL 
MG. SDL 
memory 
MG. EDL 


c 


R. GBCF(l) 

GCNT(2) 
GDAT(256) 
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C. 3. 4 Generic Access Service Processing Considerations 


Generic access routine provide applications with a method of 
accessing devices genericallg. That is* an application mag request to 
issue a read from a device and not need to provide the device specific 
information required to do the GIO. This implies that the generic 
access module of a DIM has the logic to translate a generic req.uest 
code in to a series of steps required to set up/ execute/ and evaluate 
completion status in device—specific terms. 

As with the other servers/ the context of the request is passed 
to the DIM with R5 containing the address of a line control bloc.k. 
The LCB points to a generic request message. The information that is 
provided bg a generic request message is shown in the figure below. 
These offsets are defined in the macro GENMS* of MACROLIB. 

! M. CODE { 


Standard message 


I R. GSEG 


header 



M. DATA 


R. GDID 


i R. GSTS { 

I R. GADR { 

I <15 wor d s) { 


R. GBOF 


R. GATY 


R. GCNT 


■h - — - 

I 

I 

I R. DDAT 

! (Optional/ 256 bgtes max) 

I 

I 

I 1.— p— 






M. CODE(2) 
R. GSEQ(2} 
». GDID<2> 
R.GSTS(2) 
R.GADR(30) 

R. GATY(l) 


BU The generic function code of the request 
BU The sequence number of the request 
BU The device lo-gical identification 
BU The generic service status return code 
BU The PD data address in internal BASEWAY 
format 

C The address tgpe: 

0 ~ Bit address 

2 * Phgsical address 

4 » Logical address 
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C.4 DIM - Utility Macros and Subroutines 
4. 1 Code-Generating Macros 


The following macros are defined in the DIM library for utility 
and coding clarity. They are quite helpful in writing Device 
Interface Modules. The following is a list of these macros. 


ASDIM^ 


DTINI$ 

DTFNC* 

DTMDL* 

DTMFR^ 

ERTBL» 

MPLCB« 


Pop AST parameter (address of LCB into R5)# 
save registers R(j-R5# restore mapping 
context of message buffer associated with 
the LCB. 

Initialize device/function tables. 

Create a function branch table entry. 

Create a device model table entry. 

Create a device manufacturer table 
entry. 

Create a device-specific status to generic 
statu return translation table entry. 

Map the message buffer associated with 
the current LCB. 


. 4. 1. 1 


orm: 


ASDIM« - 
ASDIM» 


vokes the macros ASTSV^ and MPLCBIi. ASTSV^ saves registers R0-R5 
•i/nile it pops the AST parameter off the stack and puts it in R5. pops 
the AST parameter^ the address of the LCB associated with the AST. 
MPLCB^ This macro pops an AST parameter off the stack and stores it in 
R5^ saves the original contents of R0-R5 on the stacks remaps the cont 


C. 4. 1. 2 DTINI4 - 

Form: DTINI$ <Imanufacturer table label> 


Initializes the PSECTS for the manufacture# . . MFR# the model# 
. . MDL# and function branch# . . FNC tables. 
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use. 


The actual processing of the generic request is accomp 1ished fay 
traversing through function branch tables. These tables are made up 
of entry points of routines/ uihen called in the sequence of the table/ 
mill perform the function associated with that table. The function 
branch table table is determined by Manufacturer/model/function 
tables. 


For sac 
models asso 
mhich pairs 
generic mes 
branch table 
in section 
SQSNFC may b 
current requ 


h 'manufacturer supported by the DIM# there is a table of 
ciated uiith it. Each model is associated with a table 
the generic-function and addressing type (R. QATY in the 
sage) uiith the beginning address of the proper function 
The macros DTINI*? DTFNC$» DTMDL'S/ and DTMFR^ described 
C. 4. 1 are used to build these tables. The subroutine 
e used to determine the function branch table for the 
est. 


The follouiing steps should prove to be useful in designing and 
uiriting a generic access routine for a device interface module. The 
first step should be to analyze uihat steps are required to perform all 
the supported function for devices that are to use the DIM. Keeping 
in mind the following items. 

- Because the service must support multiple interfaces at the 
same time/ DIM code must be reentrant. 

- Use the C. SAVE buffer in the LCB to maintain the context of 
the current GIO. These parameters may be needed if a retry 
for a timeout condition is desired. 


QIus should be done uiith a completion AST routine. 

Translate device specific i/o status codes (success and 
error) into generic service status values. This is the only 


uiay that the servers uiill be 
f al iure. 

Deallocate any free memory 
allocate during the processing 

Call *PDDON uiith the required 
function. $PDDON must be 
properly performed or not. 


able to determine succes or 


buffers that may have been 
of the function. 

parameters uihen terminating a 
called uihether the function uias 


Refer to 
construct the 


the sample DIM for a more 
generic routine. 


detai1ed 


example of houi to 
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C. 4. 1. 5 DTMNF< - 
”orm: DTMFFIi TJi^gr 

m-Pgr = BASeWAY manuYacturer code or 0 


Creates an entry into the manufacturer table. The table entry 
consists of the manufacturer code in the first word and the current 
address of the PSSECT . . MDL in the second word. This will become the 
first address of the next model table built using the DTMDLS macro. A 
null parameter will generate a zero word and terminate the current 
manufacturer table. The m-anufacturer table is built in the PSECT 
. . MFF. 


C. 4. 1. 6 ERTBL« - 

Form; ERTBLS deverr^ generr 

deverr = The device specific error code returned 
by the driver or ACP. 

generr » The generic status code that the device 
error is to be translated to 


Creates an entry into the generic error message table translation 
table. The entry is in the for.m of the device-specific i./o status 
-ede is in the first word and the generic status message is in the 
'cond word. 
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C. 4. 1. 3 DTFNC$ - . 

Form: DTFMC* fnccod.- CbitfncI# CphyfncJi ClogfncI 


fnccod * generic function code 

bitfnc « address of the bit operation 

function branch table. Zero if 
und efined. 


phyfnc =« address of physical operation 
function branch table. Zero if 
und efined. 

logfnc « address of logical operations 
function branch table. Zero if 
und efined. 


Creates an entry into the function branch table. The entry 
consists of the generic code in the first word. The address of an 
aopropriate bit function branch table is in the second word. The 
third word is the appropriate physical operation entry point to its 
function branch table. The fourth word contains the entry point to 
the appropriate logical function branch. A null parameter for the 
•nacro will generate a zero word. This zero word will ter.minate the 
table. The function branch table is built in the PSECT . FNC 


C. 4. I, 4 DTMDL$ “ 

Form; DTMDL* model 

model s BASEWAV modal coda or C 


Creates an entry into the model table. This table entry consists 
of the model code in the first word and the current address of the 
RESECT . .FNC in the second word. This will become the first address 
of the .next function branch table to be built using the DTFNCS macro.- 
A null parameter for the macro will generate a zero word and terminate 
the current model table. The model table is built in the PSECT . . MDL. 
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C. 4. 2. 1 ^ENFC - 

Subroutine ♦OENFC - GENERIC FUNCTION TABLE LOOKUP MODULE 

The purpose oF this module is to perform table lookup 
operations determining the proper function branch table 
used to execute the generic function i/o request. The 
address of the function branch table is then passed 
back to the calling routine. 

The associated tables are defined in the following 
mamver: 


Manufacturer table 


i Manufacturer code I 


1 Address of first entry I 
! entry in the associated ' 

! model table ! 

+-----—--- — --h 


o 

o 

o 


4 —— 


—• 4 - 


0 



Model table 


! Model Number ! 


I Address of first function I 
i in the associated ! 
I generic function table ' 


o 

o 

o 
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4. 2 DIM Subroutines 


The following are utility subroutines that are use<i by DIMs. 

^GENFC - Find function branch table 
$PDDON - Server DIM completion routine 


The following pages describe these routines in detail. 
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C. 4. 2. 2 $PDDON - 

The subroutine ^PDDON is called by the DIM when it has compie 
vfie PD access service request* successfully or unsuccessfully, 
primary functions of <PDDON are: 

o update service error statistics 

o return the service request response message to the requesting 
party 


0 clean up and dispose of the current LOB 

0 reenter the DIM if there are any more LCDs queued to the 
current LAB. 


Because each server has different requirements and message 
formats* there is a ^PDDON routine for each of them. In general the 
DIM needs to pass the following information to the 1»PDDON. 

Calling Sequence: 


CALL ^PDDON 


Input Parameters: 



R1 


The number of data bytes that are to be 

returned to the requestor as a result of the 
service. Zero if there are none. 


R5 * Address of the current LCB with the following 
fields modified 


C. lOSB = i/o status block of the service i/o 
(should be zeroed by the DIM if no 
i/o was performed) 


C. SRVS 

Output Parameters: 


Generic service status code of the 
service request 


None 



Since the purpose of ^PDDON is to clean up the 
current request context and establish the next'.. 
a DIM routine should clean up the stack and 
return or perform an AST exit. 
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Generic function table 


Generic function #1 


Address of associated bit 
function branch table 


Address of associated physical 
function branch table 


Address of associated logical 
function branch table 



The last entry in the manufacturer# model# and function 
table is a 0. 


Library: DIMLI3. 0L3 
Calling Sequence: 

CALL SOENFC 
Input Parameters: 

RO Address of first entry in the Manufacturer 
function tables 

R5 Address of current Line Control Block <LCB). 

It is assumed that the. generic access message 
has been mapped and the address is stored in 
C. MADR<R5). 

Output Parameters: 

RO Address of first function entry point in the 

resulting function branch table 

R1 Address of first QIQ function code to be issued. 

R5 Preserved 
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. 5 Example DIM 


Copyright (C) 1984 

Digital Equipment Corp. > Maynardi Mass. 

This software is furnished under a license and may be used and copied 
only in accordance with the terms of such license and with the 
inclusion of the above copyright notice. This software or any other 
copies thereof may not be provided or otherwise made available to any 
other person. No title to and ownership of the software is hereby 
transferred. 

The information in this software is subject to change without notice 
and should not be construed as a commitment by Digital Equipment 
Corporation. 

DIGITAL assumes no responsibility for the use or reliability of its 
software on equipment which is not supplied by DIGITAL. 

Subroutine $xxDIM - SAMPLE DEVICE INTERFACE MODULE 

The .tx Device Inter^Bc b Module (DIM) is provided as a 
template for users who wish to write their own DIM'to support 
programmable devices other than those already supported by 
the SHOP FLOOR GATEWAY. 

This template shows simple and concrete examples for writing 
DIMS. Explanations and code comments 

guide the novice through the concepts and features of DIMs. 

For the novice# the template builds a simple terminal server which 
performs familiar TTy reads and writes* For the more advanced 
coder* examples are given for actual PLC servers. Additionally* 
coding features and important points are highlighted for added 
and improved functionality. 

Generally* the template consists of descriptor tables 
and four functional modules. 

The descriptor tables define parameters like the manufacturer 
of the device accessed by the DIM* the model number of the device* 
the functions performed by the device* and the possible functions 
for generic service. 

The first module is the i/o cancellation module. This module 
is responsible for performing a disconnect operation from the 
DIM—supported programmable device. This operation may not be necessary 
for a particular device type such as a terminal server. 
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; The second module is the i/o initialization module. This 

fliodule contains the code required' to connect to the appropriate device 
; driver and/or ACP before accessing the communications interface(s). 

} The third module is the Direct Access Service module. This 

; module contains the code required to perform remote GIOs to the xx 
; interface. 

i 

} The fourth module is the Generic Access Service module. This 

; module contains the code required to perform generic operations to 
i XX devices. 


i NOTE: Before a Device access server can access a DIM/ the 
/ following must be done: 

} 

/ 2) Assemble the module DIM source and insert into the 

; object library SFQ$LIBRARY: DIMLIB. 

i 

3) Make an entry for this module in the device vector 
table DSVECT (DEVVEC. MAC) by adding the following 
line: 

/ DErDIM XX ; Add xx support 

j 

; 4) Reassemble and insert D^VECT into the object library 

;• SFQ^LIBRARY: DIMLIB. 

/ 

5) Relink the Device access servers and move the 

resulting images to SFGSSYSTEM with the following 
VMS DCL commands: 

t SET DEFAULT SFO^ROQT: CSOURCE. POLSRVj 
^ TKB dPOLSRV. TKB 

; 4 COPY POLSRV. TSK SFG^SYSTEM: 

$ SET DEFAULT SFGSROOT: CSOURCE. GENSRVl 
; ^ TKB GGENSRV. TKB 

t COPY QENSRV. TSK SFG^SYSTEM: 

; ^ SET DEFAULT SFG^ROOT: CSOURCE. DIRSRVI 

TKB SDIRSRV. TKB 
S COPY DIRSRV. TSK SFG^SYSTEM: 

Library: DIMLIB. OLB 

f • 

Language: PDP-11 Macro 


Creation date: 
Modification history: 


C-2S 


Dffvice Interface Modules 



C-29 


Device Inter-Pace liodules 


. PACE 

. SBTTL Macro declarations and definitions 


. MCALL LAB«, LC3«> SENMS^, DIRHS$, ASDIMS. 3AVR0S 

. MCALL . RESRC«. DTMDL* QIO^S, CATEP^. ASTX«S/ SRVSCS 

. MCALL D^CD<P MXCOD«, TBSI2S, DTMFR«, DTFNC^, DTINI^ 

. MCALL ERTBLS, OIOW^S 


OATEP^ 

CENMS* 

DEVCD» 

SRVSC» 

DIRMS* 

MXCOD«‘ 

LABS 

LCBS 


Qateuiay parameters 

Define Generic Access message offsets 

Device names and model codes 

Generic service status codes 

Define Direct Access message offsets 

Define mailbox message codes 

Define Line Access Block (LAB) offsets 

Define Line Control Block (LCB) offsets 
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. PAGE 

. SBTTL Data def initions 


Device-'specific i\o function table 


; Valid direct service QIO functions for the DIM-supported devices. 
; xx.WRT^ etc. are previously defined symbols. 

; The following table is defined for validating QIO functions sent 
for direct servicing. 


xxVQIO; 


X X NBRQ 


WORD 

10. WLB 


WORD 

10. WRT 


WORD 

10. BWT 

i 

WORD 

10. RLB 

i 

WORD 

10. RED 


WORD 

10. BRD 

i 

WORD 

10. DAG 

; 

WORD 

10. STP 

; 

WORD 

10. STR 

i 


<. -xxVQI0>/2 


Logical write function 
Write function 
Bit write function 
Read function 
Read function 
Bit read function 
Diagnostic read 
stop device 
start device 

Number of entries in table 


Generic error messaae code table 


; Creation of the error table associating lOSB error with 
; error 


Entry 

number 

one^ 


i/o status error 
generic error code 


generic 


lOERR: 

ERTBL$ IS. sue. SS. SUC 
ERTBL^ IS. TMO, SE. TMO 
ERTBLS IE. TMO. SE. TMO 
ERTBLS IE. SRE. SE. PRO 
ERTBLS IE. OFL. SE. OFL 
ERTBLS IE. DNR. SE. TMO 
ERTBL« IE. ABO. SE. CAN 
ERTBL^ IE. BCC. SE. TMO 


; I/O successfully completed 
; Successful, but timeout 
Timeout 

; Send reply message error 
; Off line 
; DZ timeout 
; Function canceled 
Block check error 
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} End o-P I/O error table 
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TBSIZt IQERRi lOEROT 
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. PAGE 

. SBTTL Manufacturer/model function tables 


The manufactureri model/ and function tables are defined 
here and used to process generic functions requested by the 
user to the supported equipment. Each manufacturer may have 
several models* each model may support several generic 
functions. Those models which use identical functions tables 
may share the same table. 


Manufacturer/model names and codes are defined in the 
macro DEVCD^. For this example the manufacturer will have the 
code MF. XXX and will have 3 models/ MD. xaA/ MD. xxB* and 
MD. xxD. Assume that MD. xxA and MD. xxB are similar devices and 
use the same logic to perform their functions. 


DTINI$ 

DTMFR^ 

DTMDLS 

DTMDL$ 


xxTBL 

MF. XXX 

MD. X xA 
MD. X xB 


/ Initialize manufacturer table 

/ Start table for manf. XXX 

; Make entries for modules MD. xxA 
/ and MD. xxB. Note that they 
/ share the same function table 


DTFNC« 

DTFNC$ 

DTFNC$ 

DTFNC$ 

DTFNC$ 

DTFNC$ 

DTFNC$ 

DTFNC* 

DTFNC$ 

DTFNC$ 


DTFNC$ 

DTFNCS 

DTFNC* 

DTFNCS 

DTFNC* 

DTFNC* 

DTFNC* 

DTFNC* 

DTFNC* 

DTFNC* 


MG. RED/BITRD/PHYRD/ LGCRD 
MG. WRT, BITWR, PHYWR/ LGCWR 
MG. WTV, BITWV/ PHYWV* LGCWV 


Read routines 

Write routines 

Write verify routines 


MG. RDS/ RDSTA 
MG. SRD/ START 
MG. SPD/ STOP 
MG. SUL/ UPREQ 
MG. EUL/ UPEND 
MG. SDL/ DNREQ 
MG. EDL/ DNEND 


DTMDL* MD. xxC 


Status 

Start device 
Stop device 
Upline load request 
End upline load 
Downline load request 
End downline load 

Define the functions for the 
model MD. XXC 


MG. RED/ CBITRD/ PHYRD/ CLGCRD 
MG. WRT/ CBITWR/ PHYWR/ CLGCWR 
MG. WTV/ CBTTWV/ PHYWV/ CLGCWV 


MG.RDS/RDSTA 
MG. SRD/ START 
MG. SPD/ STOP 
MG. SUL/ UPREQ 
MG. EUL/ UPEND 
MG. SDL/ DNREQ 
MG. EDL/ DNEND 


Read routines 

Write routines 

Write verify routines 


Status 
Start device 
Stop device 
Upline load request 
End upline load 
Downline load request 
End downline load 
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DTFNC$ 

DTMDLf 

DTMFR^ 


/• Terminate the model table 
; Terminate manufacturer table 



Device Inter-Pace Modules 


. PACE 


« X X D I M — ENTRY POINT TABLE 



; This is the entry*point table for the routines of this 

; Device interface module. The Device Access Service Tasks use 
; this table to determine the entry points for appropriate DIM 
; routine. The order of the entry points is important since the 
; Device Access servers reference them by their offset from 4xxDIM. 

The order is; 


. xxCAN Cancel routine transfer address 
. xxINI Initialization routine transfer address 
. xxDIR Direct access service routine transfer address 
. xxQEN Generic access service routine transfer address 


Sx xDIM: : 

.WORD . xxCAN 

.WORD . xxINI 

.WORD . xxDIR 

.WORD . xxGEN 


r MUST BE GLOBAL 

} Cancel service transfer address 
i Initialization service transfer addres 
; Direct access service transfer address 
i Generic access service transfer addres 


s 
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. ENABL 

LSB 



«xCAN: 

If 

SAVRG4 

<R4> 




MOV 

C. LAB(R5). R4 


R4 points to LAB this block is queue 


GI0W4S 

#10. DAC/ L. LUN(R4), 

#EF. PD« f R5 i Deaccess LUN 


BCC 

204 

/ 

BR if directive successful 


MOV 

, 4DSW, C. SRVS(R5) 

/ 

.use DSW4 error for generic 




} 

code 


BR 

404 

i 

and return. 

; Determine uihat uihat generic status value to return from the 

; lOSB 

and the 

10 error table. 



504; 

MOV 

#IOERR.R.l 

} 

RJ points to i/o status? error table 


MOV 

#IOE.RCT, R2 

} 

R2 points to Size of error table 

254: 

CMPB 

C. I0SB(R5), (R1) 

/ 

Determine i/o status 


BEG 

304 

/ 

go to insert generic function 


ADD 

#2. R1 

i 

Trg next entry 


SOB 

R2. 254 


Do until end of table 


MOV 

#SE. FNRy C. SRVS(R5> 

i Function error 


BR 

404 



304: 

MOVE 

1 (Rl), Ri 

i 

Move in error 


MOV 

Rl.. C. SRVS(R5) 

} 

Insert generic status 

4: 

CLR 

Rl 

f 

Error - zero byte cnt 


CALL 

RETURN 

4PDD0N 

i 

clean up operations 


. OSABL 

LSB 
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. PACE 

. SBTTL .xxINI - initialixation service routine 


X X I N I — SERVICE INITIALIZATION ROUTINE 


; This fliodule performs the necessary actions required to 

; initialize access to an xx inter-face line 


j Input: 

R5 » Address o-f Line Control Block (LCB) containing 
; initialixaton request parameters: 

C.LAB » Address Line Access Block (LAB) to perform 
; initialization 


Output to PDDON^: 

; R1 * 0 since there is no data to be returned 

; R5 * Address of LCB used in this operation passing back 

; the offsets containing following information: 

C. lOSB 3 I/O status block of the i/o deaccess 
operation(s) 

C. SRVS * Service status code sent back to. servers 
SS. sue for successful completion other 
codes the server may expect are located 
in the macro SRVSC^. 
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. ENABL LSB 

. X X INI; 

SAVRGS <Rl>R2iR4> ; save and restore registers 

MOV C. LAB<R5)iR4' ; get LAB for this block 


i Issue access QIO 


QIOW^S #10. ACW, L. LUN<R4), #EF. PD, / R5 

BCC 20< , BR if directive successful 

MOV $DSW, C. SRVS(R5> ; use DSWK error for generic 

; code 

BR 40< } and return. 


; Determine uihat what generic status value to return from the 
; lOSB and the 10 error table. 


20 ^: 

MOV 

MOV 

25 $: 

CMPB 

BEG 

ADD 

SOB 

MOV 

BR 

: 

MOVB 

MOV 


#IOERR,R1 
#IOERCTiR2 


R1 points to i/o status error table 
R2 points to Size of error table 


C. IDSB(R5>, (RJ > ; 
30 $ ; 

#2, R1 

R2,25$ , 

#SE. FNR,‘C. 3RVS(R5) 


Determine i/o status 
go to insert generic function 
Try next entry 
Do until end of table 
; Function error 


40$ 


1(R1)/R1 5 Move in error 

Rl,C. SRVS(R5) j Insert generic status 


40$: CLR R1 

CALL $PDDON 
RESRG$ CR4, R2, Rl> 
RETURN 
. DSABL LSB 


) Error - zero byte count 
i clean up operations 
; save and restore registers 
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. P AQE 

. SBTTL . xxDIR - direct access service routine 


X X D I R — DIRECT ACCESS SERVICE PROCESSING ROUTINES 


} This ffliodule provides the actions req^uired to perform a 

i direct access 010 as defined in the direct access service 
i request message. 

i This direct access service routine performs the following: 

/ * . 

; 1) Validates the GIG function code sent with the GIC 

/ function code table (xxVGXO) 

} 

} 2) Validates the device dependent parameters sent in the 

; service request message starting at R. DPRM 

; 3) Sets up the directive GIO function with the GIO 

completion AST parameter set to #xxDAST 

4) Determines if GIO was invoked successfully. If the GIO 

was unsuccessfully dispatched# sets proper status codes 
; and calls ^PDDON to clean up before returning to server. 

i 

5) Saves registers and restores mapping context of the 

mailbox message with the ASDIMS macro 

; 6) Depending' on the type of device supported# checks for time 

outs or block check errors# then retries the GIO the number 
; of times indicated in the C. TRY offset of the LCD. 

7) Determines success or failure of the i/o completion# sets up 
the following offsets in the LCB and request message. 

— C.3RVS — generic status message code datarmined 
> from i/o error to the generic status routine 

- R. DIOS - i/Q status from C. I05B 
i - R. DIOC - i/o byte count from C. I0SBr2 

i 

S) Determines if a read was invoked# if so# sends the byte 
countinRlto PDDON. R5 still must point to the 
beginning of the current LCB. 

; 9) Calls SPDDON 

f 

10) Restores registers in the following order with the RESRG^ 

; macro: <R0# R1» R2# R3. R4.. R5> 
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Input: 


R5 = Address of Line Control Block <LCB) 
containing the context of the cancel 
request. Offsets are: 


C. LAB s Address of the Line Access Block (LAB) 
of the interface to perform the cancel 
request on. The primary field th^t is 
used from this block is the logical unit 
number at L. LUN. 


C. MPNT = Block pointer to the direct service 

request message. This value is used in 
mapping the message in the servers task 
space. 

C. MLEN = Length of direct service request message 

in number of blocks. This is also used in 
the mapping of the message. 

C. MADR = Mapped address of the direct service 
request message. This address is only 
valid if the message has been mapped. It 
is mapped uihen the server calls this 
module at the entry point xxDIR. It must 
be remapped when the executing completion 
AST or if anything else destroys the 
mapping context. The format and values 
of the message follow (offsets defined 
in macro DIRMSO. 


R. DSEQ = Request sequence number. 

R. DDEV = XX (Interface name in ASCII). 


R. DUNT 
R. DFNC 
R. DPRM 


R. DDAT 


Interface unit number. 

QIO function^ode to use for the request. 

Array of 6 words containing the 
device-specific optional- parameters for 
the GIG. 

Beginning of the request data buffer. 
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Output to PDD0N4; 

R1 » Number o-P data bytes to return to requestor 
starting at o-PPset R. DDAT in the direct 
service message. 

R9 * Address oP LCB used in this operation passing 
back the oPPsets containing following 
information: 

C.lOSB a I/O status block of the i/o deaccess 
operation<s). 

C. SRVS * Service status code sent back to servers 
SS. sue for successful completion) other 
codes the server may expect are located 
in the macro SRVSC*. 


C. ML£N * Block length of the message buffer. 

C. MPNT » Block pointer of the message buffer. 

C. MADR * Mapped address of the direct service 
with the following oPPsets updated: 

R. DDSW •» Directive status word of QIQ 
invocation. 

R. DIOC * I/O count in bytes that resulted 

from the QIO. 

R. DDAT a Beginning of data data to be 
returned buffer. 
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. ENABL L3B 

xDIR: : 


3AVR0S '•CR4/R3i R2> * Save registers 

MOV C. MADR<R5)»R3 j R3 points to Beginning of direct 

MOV R. DFNC(R3) i C. SAVE(R5) ; Direct QIO function code 

MOV R3i R. DPRM(R3) ; Beginning of data message 

ADD #R. DDATiR. DPRM<R3) ; Address of data buffer 

MOV R3« C. SAVE'^2(R5) ; Beginning of data message 

ADD #R. DPRMj C. SAVE'r2(R5) / Address of parameter block 

Determine if QIO function code is valid 



MOV 

#xxNBRG.R2 

I R2 points to Number of xx GIOs 


MOV 

#xxVQI0/R4 

/ R4 points to Beginning of xx GIO 

5S: 

CMP 

R. DFNC(R3)# (R4)+ } Find match in table 


BEG 

10$ 



SOB 

R2> 5$ 

i No match - try next entry 

; Bad 

GIO function from direct 

access server mailbox 


MOV 

#SE. FNR/R. DDSW<R3) ; Simulate bad directive 


CLR 

C. lOSBCRS) 

/ Clear 1st word lOSB 


CLR 

C. I0SB+2(R5) 

; Clear lOSB byte count 


BR 

DIRERR 


Test 

size of 

message buffer 


10$: 

TST 

R.DPRM+2<R3) 

; Test for neg or zero count 


BLE 

20$ 

i 


CMP 

R. DPRM-t-2(R3)> #R 

. DLDT ; Test greater than max size 


BLE 

DIRGIO 

; Perform GIO 

i Invalid length of buffer 


20$: 





MOV 

#IE. IBS# R. DDSW<R3) ; Move inv bi^^f count message 


MOV 

#SE. CNT/ C. SRVS<R5) ; Bad count status code 


CLR 

C. IOSB<R5) 

} Clear 1st word of lOSB 


CLR 

C. I0SB+2<R5) 

; Clear byte count in lOSB 


2R 

DI-RERR 



Issue GIO« R2 holds address to the six device~specific 
parameters 


DIRQIO: 


MOV #SE. FNRi C. SRVS(R5) ; Assume error code 

MOV C. SAVE<R5)/R2 ; R2 points to Device param block 

MOV C. LAB<R5KR4 ; Get LAB for this block 


data 


func tions 
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MOV L. LUN(R4}iR4 ; Need space on QIO line 

OIO<S C. SAVE<R5)> R4, . , R5. #xxDAST, <(R2), 2<R2>. 4(R2), 6(R2), 8. (R2), 10. (R2) 

MOV 40SU* R. 0DSU<R3) i Save directive status utord 

BPL DIREND 

i Set up status codes before returning with GIO failure 
; R3 points to start of data area 

OIREHR: 

MOV C. I0SBCR5), R. DI0S(R3) i Save i/o status 

CLR R. DI0C<R3) ; Zero i/o .byte count 

CLR R1 i R1 points to number of bytes read 

CALL 4FDD0N ; Clean up 

} End of Direct access service processing 

DIREND; 

RESRO< <R2^R3*R4> i Restore registers 

RETURN 
. DSABL LSB 
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X X DAST: 


; This is the i/o completion AST routine for a Direct service 

request. It is responsible for evaluating the completion of the 
i i/o operationi setting up the parameters required by $PDDON/ 
f and calling SPDDON to return the request and clean up for the 
, next request. 

; Inputs: 


(SP) * AST parameter^ the lOSB of the GIO function. 

This address also points to the offset C. lOSB 
of the LCB associated with the QIO. 

AST parameter is popped from stack and all registers 
are preserved . 


ASDIMS ; Pop AST parameter (address 

; of request's LAB) and put 
; into R5 and save registers 
i R0-R5 on the stack. 

; Remap the message buffer 
; referenced by the LCB (map 
i C. MLEN<R5) blocks starting 
; at block C.MPNTCRS)) and 
; store the resulting address 
i in C. MADR(R5). 


Determine if there .has been a time out or block check 


lOS: 


CMPB 

BEG 

CMPB 

BNE 

DEC 

BLE 

CALL 

BR 


C. I0SBCR5). #IE. TMO 
10 $ ‘ ; 

C. I0SB(R5). #IE. BCC 
20 -* ; 

C. TRY(R5) ; 

20 ^ ; 

DIRQIO ; 

100 * } 


i Test for time out condition 
Yes# decrement count and retr^ 

; Test block check condition 
No# determine status and condition 
Number of retries 
Done trying - continue 
Retry direct service QIO 
Qo to end of AST 


) Determine generic message/error response 


20*: MOV 

MOV 
MOV 


C. MADR(R5), R3 
#IOERR,R1 
#IOERCT# R2 


; R3 points to Beginning of data 
i R1 points to Error table entry point 
; R2 points to Number of entries in 
error table 


C-45 







Device Interface Modules 


30t: CMPB C. I0SB(R5>^ (R1) ; Determine i/o status 

QNE 40'$ ; Didn't match/ go set up next 

; Found i/o status return code/ send equivalent generic error message 

MOVB 1(R1;.R1 ; Bgte generic error 

MOV RliC.SRVS<R5) ; Insert generic status 

BR B0$ / Co to determine byte count 

; Point to next entry in error table an^ try again 
; If at end of table use default error message and continue 

40$: ADD #2/Rl ; Try next entry 

SOB R2/30$ ; End of table? 

MOV #SE. FNR/C. SRVS<R5> / Default generic error message 

} Set up number of bytes to return# send to $PDDON 

50$: CLP R1 / Zero for other than read 

MOV C. MADR(R5>»R3 / R3 points to Beginning of data 

CMP R. DFNC(R3)/ #xX. RUP ; Test for read function 

BEQ 55$ / Read/ move number of bytes read 

CMP R. DFNC<R3)/#xX. RPR ; Test for read function 

BEG 55$ / Read/ move number of bytes read 

CMP R. DFNC(R3) / #xX. DAO ; Diagnostic read 

BNE 60$ 

55$: MOV C. SAVEr2(R5>/R1 ; R1 points to Number of data bytes 

Save status and byte count then return 

60 $: 

MOV C. iaSB(R5>/R. DIQS(R3) ; 

MOV C. iaSBr2<R5), R. DI0C<R3> ; 

CALL $PDDON ; Perform 

Exit direct service AST 

100$: RESRO$ <R0/R1 / R2/R3/R4/R5> i Restore registers 

ASTX$S ; Exit AST (param already popped 

RETURN 
.DSABL LSB 


Save i/o status 
Save i/o byte count 
direct access cleanup 
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. PAGE 

. SBTTL . xxGEN - generic access service routine 


X X G £ N 


GENERIC ACCESS SERVICE PROCESSING ROUTINES 


This module accepts a generic access requests determines 
and executes the device specific steps required to perform the 
request. 

The generic functions are defined and specified at the. 
beginning of the DIM in the manufacturer/model tables <xxTAB.>. 
These functions are composed of a sequence of subfuncticns 
defined below. 


The generic processing routine executes in the following order: 

1) Set up entry point to manufacturer/model table in RO 

2) Call SGENFC - finds associated function branch table for 
the generic service requested. 

3) Determine if SGENFC returned with an error (RO is negative) 

- error will be due to a model number or manufacturer 

requested in the QIO was not found in the manufacturer/ 
model tab le. 

4) If no error occurred/ begin processing the generic request 
by executing the code pointed to by each entry point 
listed in the appropriate function branch table 
(determined by SGENFC). RO contains the address of the 
first function entry point. R1 contains the address of 
the first QIO function code. 
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i INPUT: 


R5 


Address of the 
containing the 
service reques 


Line Control 
context of a 
t. Applicable 


Block (LCB) 
generic access 
offsets are: 


C. LAB 

C. STN 
C. SLAV 
C. SXTN 
C. MNFR 
C. MODL 
C. MLEN 
C. MPNT 
C. MADR 


Address Line Access Block (LAB) of the 

interface that the device is located on. 

Station address of the device 

Slave station address of device 

Extended address 

Manufacture code of the device 

Model code of the device 

Block length of the message buffer. 

Block pointer of the message buffer. 

Address of the beginning of the mailbox 
message containing the request. Also 
the address for the response.. The incoming 
message is formatted as follouts: 


R. GADR 

R. GCNT 
R. GDAT 


Data Address of the programmable 
device 

Count of data to use in i/c 
Optional device data buffer of up 
to 2S6 bgtes. Use of buffer is 
dependent on the request (read or 
write) 


Information passed through the associated LAB 


L. LUN = Logical Unit Number (LUN) to use in performing 
i/o on the device interface. 


C-4a 



Device Interface Modules 


Output to PDDON$: 

0 

R1 » Number of data bytes to return to requestor 
starting at offset R. GDAT in the direct 
service message. 

R5 » Address of LOB used in this operation passing 
back the offsets containing following 
information: 

C.lOSB * I/O status block of the i/o deaccess 
operation(s). 

C. SRVS = Service status code sent back to servers 
SS, sue for successful completion) other 
codes the server may expect are located 
in the macro SRVSC*. 

C. MLEN « Block length of the message buffer. 

C.MPNT * Block pointer of the message buffer. 

C. MADR = Mapped address of the direct service 
with the following offsets updated: 

R. ODAT = Beginning of data data to be 

returned buffer. 
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; C. SAVE uiill be used in the follouiing uiay. The 
; nay use them in any uiay that makes life easy. 


programmer 


C. SAVE 
C. SAVE+2 
C. SAVEr4 
C. SAVE+6 
c. SAVE+e, ■ 
C. SAVErlO. 
C. SAVE+12. 

C. SAVE+14. 

C. SAVErl6. 
C. SAVE+IS. 
C. SAVE+20. 
C. SAVE+SO. 


Address of current QIO function 

Address of data buffer 

Count (bits#bytes or words) requested 

Address.of PD address buffer (allocated) 

Subfunction coda 

Current completion AST address 

Assigned when new buffer allocated 

(previous buffer addr) 

Temporary storage for computed byte count 
(bit functions) 

Actual length of address buffer 
Actual length of buffer 1 C23 

Actual length of buffer 2 C123 - 

Error exit branch • 


Function branch tables 


Read register function entry 


WORD 

• 1 

WORD 

10. RLB 

WORD 

LCBINI 

WORD 

CNVBYT 

WORD 

BYTCHK 

WORD 

GENQIO 

WORD 

GENEND 


WORD 

GIOEXM 

WORD 

CLNUP 

WORD 

ASTEXT 


points 

; Logical Read of Register 
.• Issue one QIO function 
i Logical read 
i Initial register setup 
} Convert registers to bytes 
; Validate byte count 
» Issue requested GIQ function 
; End generic function the nest 
; tiiord contains the next .jump 
i after entering the AST 
; Test for successful GIO 
; Success clean up, call FDDON 
; Exit AST 


CLGCRD: 


. WORD 1 

. WORD IQ. RLB 

•WORD LC3INI 
. WORD ALABUF 

. WORD CNVBYT 

. WORD BYTCHK 

. WORD GENQIO 


Logical Read of Register for 
; XXC devices 
i Issue one GIO function 
i logical read 
; Initial register setup 
> Allocate address buffer 
; Convert registers to bytes 
i Validate byte count 
; Issue requested GIO function 
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WORD 

GENEND 

i 

End generic function the next 



i 

word contains the next jump 



} 

after entering the AST 

WORD 

QIOEXM 

i 

Test for successful QIO 

WORD 

CLNUP 

i 

Success clean up/ call PDDON 

WORD 

ASTEXT 

i 

Exit AST 


i Write register generic function 


entry points 


LGCWR: 

. WORD 

1 


. WORD 

10. WLB 


. WORD 

LCBINI 


. WORD 

CNVBYT 


. WORD 

BYTCHK 


. WORD 

GENQIO 


. WORD 

GENEND 


WORD 

QIOEXM 

WORD 

CLNUP 

WORD 

ASTEXT 


; One QIO operation 
; Logical write 
; Initial register setup 
i Convert register cnt to bytes 
; Validate byte count 
/ Issue requested GIO function 
/ End generic function 
; word contains the next jump 
f after entering the AST 
; Test for successful QIO 
; Success clean up/ call PDDON 
Exit AST 


QCWR: .WORD 1 

. WORD 10. WLB 

.WORD LCBINI 
. WORD ALABUF 

.. WORD CNVBYT 

. WORD BYTCHK 

. WORD GENGIO 

. WORD GENEND 


. WORD QIOEXM 

. WORD CLNUP 

. WORD ASTEXT 


One QIO 

operation 




Logical 

write 




Initial 

register 

set 

up 


Allocate 

address 

buf 

f er 


Convert 

register 

cnt 

to 

bytes 

Validate 

byte count 



Issue re 

quested QIO 

fun 

c ti on 

End generic funct 

ion 



word con 

tains the 

ne 

xt 

j ump 


i after entering the .AST 
• Test for successful QIO 

Success clean up/- call PDDON 
/ Exit AST 


/ Write/verify register generic function entry 


points 


LGCWV: 




; 

Write/verify register gen fnc 

WORD 

2 


Two functions performed 

WORD 

10. WLB 

t 

Logical write — 

WORD 

10. RLB 

i 

Logical read 

WORD 

LCBINI 

} 

Initial register setup 
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. WORD 
. WORD 
. WORD 
. WORD 


. WORD 
. WORD 
. WORD 
. WORD 


. WORD 
. WORD 
. WORD 
. WORD 
. WORD 


CNVBYT 

BYTCHK 

GENGIO 

QENEND 


QIOEXM 

ALVBUF 

GENQIO 

ASTEXT 


QIOEXM 

CMPBUF 

DALBUF 

CLNUP 

ASTEXT 


Convert count to bytes 
Validate byta count 
Issue write function 
End write processing nest 
word contains address of the 
next jump returning from AST 
Test for successful QIO 
Allocate verify buffer 
Issue the Read QIO 
Exit this level of AST next 
word contains address of next 
jump returning from address 
Test for successful QID 
Compare two buffers 
Deallocate dynamic buffer 
Success! Clean up and call PODON 
Exit AST done with function 


CL5CWV: 

. WORD 2 

. WORD 10. WLB 

. WORD IG. RLB 

.WORD LCBINI 
. WORD ALABUF 

. WORD CNVBYT 

. WORD BYTCHK 

.WORD CENOIO 
. WORD GENEND 


. WORD QIOEXM 
. WORD ALVBUF 
. WORD GENQIO 
. WORD ASTEXT 


. WORD 
. WORD 
. WORD 
. WORD 
. WORD 


QIOEXM 

CMPBUF 

DALBUF 

CLNUP 

ASTEXT 


Write/verify register gen fnc 
Two functions performed 
Logical write 
Logical read. 

Initial register setup 
Allocate address buffer 
Convert count to bytes 
Validate byte count 
Issue write function 
End write processing next 
word contains address of the 
next jump returning from AST 
Test for successful QIO 
Allocate verify buffer 
Issue the Read QIO 
Exit this level of AST next 
word contains address of next 
jump returning fro.m address 
Test for successful QIO 
Compare two buffers 
Deallocate dynamic buffer 
Success! Clean up and call PDDON 
Exit AST done with function 


PHYRD: 





Physical Read Register 

WORD 

1 

9 

Issue one QIO function 

WORD 

lA. RED 


Physical read 

WORD 

LCBINI 


Initial register setup 

WORD 

CVTBYT 


Convert register count to by 

WORD 

VLDBYT 

} 

Validate byte count 

WORD 

GENQIO 

9 

Issue QIO requested function 
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WORD 

GENEND 

WORD 

QIOEXM 

WORD 

CLNUP 

WORD 

ASTEXT 


; Physical writes for download 


PHYWR: 

. WORD' 

1 


. WORD 

lA. WRT 


. WORD 

LCBINI 


. WORD 

CNVBYT 


. WORD 

BYTCHK 


. WORD 

GENGIO 


. WORD 

GENEND 


. WORD 

GIOEXM 

. WORD 

CLNUP 

. WORD 

ASTEXT 

; Write/verify 

register 

FHYWV; 


. WORD 

n 

. WORD 

lA. WRT 

. WORD 

lA. RED- 

. WORD 

LCBBINI 

. WORD 

CNVBYT 

. WORD 

BYTCHK 

. WORD 

GENGIO 

. WORD 

GENEND 


. WORD 

GIOEXM 

. WORD 

ALVBUF 

. WORD 

GENGIO 

. WORD 

ASTEXT 

. WORD 

GIOEXM 

. WORD 

CMPBUF 

. WORD 

DALBUF 

. WORD 

CLNUP 

. WORD 

ASTEXT 

; Bit functions 


BITRD: 


. WORD 

1 

. WORD 

10. BRD 

. WORD 

LCBINI 


; End generic function^ next 
; word contains the next jump 
; after entering the AST 
; Test for successful GIO 
} Success clean up^ call PDDON 
i Exit AST 

operations 

; Physical Write Register 
; One GIO for physical writes 
i Physical write 
; Initial register setup 

i Convert register cnt to bytes 

; Check byte count 

; Issue requested GIO 
i End generic function 
} word contains the next jump 
j after entering the AST 
i Test for successful GIO 
i Success clean up^ call PDDON 
i Exit AST 

function entry points 

; Write/verify.register gen fnc 
} Two functions performed 
; Privileged write function 
; Privileged read function 
; Initial register setup 

; Convert register count to bytes 

; Validate byte count 
; Issue writs function 
; End write processing next 
; word contains the address of 
i next jump after AST return 
; Test for successful GIO 
; Allocate verify buffer 
} Issue the Read GIO 
i Exit AST 

} Test for successful GIO 
i Compare two buffers 
; Deallocate dynamic buffer 
; Success! Clean up/ call PDDON 
; Exit AST 


/ Bit read operation 
; Unprotected read function 
r Initial register setup 
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. WORD 

VALBIT 

i 

Validate/byte align bit pointer 

. WORD 

CALCBY 

I 

Calculate number of bytes to read 

. WORD 

RSRBYT 

} 

Set computed byte count in QIC 

. WORD 

ALCBUF 

} 

Allocate dynamic buffer 

. WORD 

QENOIO 

i 

Issue QIC read 

. WORD 

GENEND 


End issuing GIO read 

. WORD 

QIOEXM 

i 

Determine successful QIO 

. WORD 

RDMVBT 

> 

Move bits to buffer 

. WORD 

DAL3UF 

j 

Deallocate dynamic buffer 

. WORD 

CLNUP 

} 

5uccess->cleanup/ call PDDCN 

. WORD 

ASTEXT 

i 

End of generic function 


BITWR: 


3ITWV: 


WORD 

1 


Bit u»rite entry table 

WORD 

IQ. BWT 

} 

Bit urrite function 

WORD 

LC3INI 

i 

Initial register setup 

WORD 

VALBIT 

} 

Validate/byte align bit pointer 

WORD 

ALCBUF 

i 

Allocate dynamic buffer 

WORD 

CALCBY 

i 

Calc number of bytes to write 

WORD 

INIBIT 

p 

Bit write initialization 

WORD 

ALSNBT 

/ 

Align bits for PC buffer address 

WORD 

ACNBYT 

} 

Convert register cnt to bytes 

WORD 

QEMQIO 

} 

Issue QIO write 

WORD 

QENEMD 



WORD 

QIOEXM 

i 

Determine successful QIO 

WORD 

DALBUF 

: 

Deallocate dynamic buffer 

WORD 

CLWUP 


SuccBss-c1eanup/ call PDDGN 

WORD 

ASTEXT 


End of generic function 


WORD 

2 

} 

Bit write verify entry table 

WORD 

10. BWT 

I 

Bit write function 

WORD 

10. BRD 

: 

Unprotected read function 

WORD 

LC3INI 

t 

Initial register setup 

WORD 

VALBIT 

> 

Validate/byte align bit pointer 

WORD 

ALCBUF 

i 

Allocate dynamic buffer 

WORD 

CALCBY 

9 

Calc number of bytes to write 

WORD 

INIBIT 

i 

Bit write initialization 

WORD 

ALGNBT 

9 

Align bits for PD buffer address 

WORD 

ACNBYT 

9 

Convert register count to bytes 

WORD 

GENQIO 

9 

Issue QIO write 

WORD 

GENEND 

9 

Leave generic routine 

WORD 

QIOEXM 

9 

Test for successful QIO 

WORD 

ALVBUF 

9 

Allocate dynamic buffer 

WORD 

RSRBYT 

:* 

Set computed byte count in QIO 

WORD 

GENIO 

9 

Issue QIO read 

WORD 

ASTEXT 

9 

Exit first AST 

WORD 

QIOEXM 

9 

Test for successful QIO 

WORD 

RDMVBT 

9 

Move bits to buffer 
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. WORD BITCMP 

. WORD DALBUF 

.WORD DALBUF 
. WORD CLNUP 

. WORD ASTEXT 

CBITRD: 

. WORD 1 

. WORD 10. BRD 

.WORD LCBINI 
. WORD VALBIT 

.WORD CALCBY 
.WORD RSRBYT 
.WORD ALCBUF 
.WORD GENQib 
. WORD GENEND 

. WORD QIOEXM 

. . WORD RDMVBT 

.WORD DALBUF 
.WORD CLNUP 
. WORD ASTEXT 


; Compare written with read bits 
; Deallocate dynamic buffer 
i Deallocate 2nd buffer 
; Success - Clean up> call PDDON 
i End of generic function 


Bit read operation 

Unprotected read function 

Initial register setup 

Validate/byte align bit pointer 

Calculate number of bytes to read 

Set computed byte count in QIO 

Allocate dynamic buffer 

Issue QIO read 

End issuing QIO read 

Determine successful QIO 

Move bits to buffer 

Deallocate dynamic buffer 

Success-’c 1 eanup/ call PDDGN 

End of generic function 


CBITWR: 


BITWV: 


. WORD 1 

. WORD 10. BWT 

. WORD LCBINI 

.WORD VALBIT 
. WORD ALCBUF 

. WORD CALCBY 

.WORD INIBIT 
. WORD ALGNWD 

. WORD ACNBYT 

. WORD GENQIO 

. WORD GENEND 

. WORD QIOEXM 

. WORD DALBUF 

. WORD CLNUP 

. WORD ASTEXT 


. WORD 2 

. WORD 10. BWT 

. WORD 10. BRD 

.WORD LCBINI 
.WORD VALBIT 

. WORD ALCBUF 

. WORD CALCBY 

.WORD INIBIT 
. WORD ALGNWD 


Bit write entry table 

Bit write function 

Initial register setup 

Validate/byte align fait pointer 

Allocate dynamic buffer 

Calc number of bytes to write 

Bit write initialization 

Align bits for PD buffer address 

Convert register counb to bytes 

Issue QIO write 

Determine successful QIC 
Deallocate dynamic buffer 
.Success"*c 1 eanup/ call PDDON 
End of generic function 


Bit write verify entry table 

Bit write function 

Unprotected read function 

Initial register setup 

Validate/byte align bit pointer 

Allocate dynamic buffer 

Calc number of bytes to write 

Bit write initialization 

Align bits for PD buffer address 
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WORD 

ACNBYT 

WORD 

GENQIO 

WORD 

GENEND 

WORD 

QIQEXM 

WORD 

ALVQUF 

WORD 

RSRBYT 

WORD 

GENIO 

WOSID 

• ASTE.XT 

WORD 

QIQEXM 

WORD 

RDMVBT 

WORD 

BITCMP 

WORD 

DALBUF 

WORD 

DALflUF 

WORD 

CLNUP 

WORD 

ASTEXT 


Read status of PD 
RDS7A; 

. WORD 1 

. WORD IQ. DAQ 

. WORD LCD INI- 

. WORD SETSTS 

. WORD QENQIO 

. WORD DENEND 


. WORD GIOEXM 

. WORD CUMUP 

. WORD ASTEXT 


START: 


WORD 

1 

WORD 

10. 3TR 

WORD 

LCBINI 

WORD 

STRSTP 

WORD 

GENQIO 

WORD 

GENEND 


WORD 

QIOEXM 

WORD 

CLNUP 

WORD 

ASTEXT 


STOP; 


WORD 

1 

WORD 

10. STP 

WORD 

LCBINI 

WORD 

STRSTP 

WORD 

GENQIO 


} Convert register count to bgtes 
; Issue QIO uirite 
i Leave generic routine 
; Test for successful QIO 

; Allocate dynamic buffer 

i Set computed byte count in QIO 
i Issue GIO read 
£sit f5TS.t AST 
i Test for successful QIO 

j Move bits to buffer 

j Compare uiritten uiith read bits 
i Deallocate dynamic buffer 
} Deallocate 2nd buffer 
; Success! Clean up/call $PDDON 
/ End of generic function 


; One status QIO function 
• Diagnostic read 
; Initial setup entry 
} Set up status QIC stuff 
/ Issue QIO requested function 
i End generic function., next 
/ word contains the next jump 
/ after entering the AST 
; Test for successful. QIC 
/ Success clean up/ call PDDON 
i Exit AST 


; One status QIO function 
; Start the device 
/ Initial setup entry 
; Set up a start/stop operation 
/ Issue QIO requested function 
j End generic function/ next 
; word contains the next .jump 
i after entering the AST 
/ Test for successful QIC 
/ Success clean uo.. call FDDON 
/ Exit AST 


One status QIO function 

Stop the device 

Initial setup entry 

Set up a start.''stop operation 

Issue QIO requested function 
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. WORD 

GENEND 

; End generic function^ next 




; word contains the next .jump 

. WORD 

GIOEXM 

/ after entering the AST 
; Test for successful QIO 


. WORD 

CLNUP 

i Success clean up^ call PDDON 


. WORD 

ASTEXT 

; Exit AST 


Fill in neces 

sary entry 

points to perform the requested 

> 

generic functions for the particular devices you're 


supporting. 



3 

TOP: 




UFREQ: 
UPEND: 
DNREQ: 
DNEND; 
ASTDP; 
NOOPEX 


. WORD 
. WORD 
. WORD 


LCBINI 

NOFUNC 

5ENEND 


; End generic function 


c 
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xxQEN; 


a^SNFC uses the entry point in manufacturer./model tables to 
determine the generic function to be processed and returns the 
entry point function branch table 

Input: 

RO points to entry in manufacturer table 
R9 points to LCB 

Output: 

RO points to function branch table for requested function 
R1 points to QIO function to be used next. (R1 < RO) 

R5 points to LCB 


^OENFC uses the entry point in manufacturer/model to determine 
the generic function to be processed and returns the entry point 
function branch table 


SAVROS 

<R5, R4, 

R3. R2/R1. j 

^0> } Save registers 

MQV 

#x xTBLi 

RO 

RO"^ints to Manf/model table 

CALL 

4GENFC 


Determine function branch 
tab 1 e 

CMP 

#-l, RO 

. 

Function error? 

BEG 

lOS 


Ye Si end generic request 

T3T 

RO 


If zerOi no-op function 

BNE 

5$ 

. 

Process specified function 

MOV 

#NOPEX> 

RO 

NO-OP function for device 

JMP 

G(RO) + 

, 

Jump to first sub function 

MOV 

#SE. FNR 

iC. SRVSCRS) } Generic function error code 

JMP 

GENERR 

J 

End generic processing for 


Generic Function Entry Points 


CBINI: 

Initialize the fields in the LCB and others so that the 
processing may begin. 

MOV #GSNERR/ C. 3AVE*>‘30. (R5) ; GENERR is the default 

; error routine for now 
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CLR 

. C. SAVE+16. (R5) 

> 

Clear allocate buffer lengths 

CLR 

C. SAVELIS. (R5) 


to indicate that nothing -has 

CLR 

C. SAVE+20. <R5) 

> 

been allocated yet 

MOV 

C. MADR<R5)> R3 

* 

R3 points to Start generic request 



i 

message 

MOV 

Rl, C. SAVE(R5) 

} 

Address of current QIO func 

MOV 

R. 0CNT<R3)j C. SAVE+4(R5) ; Save Count of data 



} 

requested 

CLR 

C. SAVE+8. (R5) 

} 

Clear subfunction 

MOV 

P.3.C. SAVE+2<R5) 

h 

Copy beginning of message data 

ADD 

#R.GDAT^C. SAVE+2<R5) » Address of data buffer 

JMP 

a<RO)+ 

} 

Goto next entry in table 


ALABUF: 


For model MD. XXCi allocate 
extended address. This is 
that the address buffer is 


memory uiithin task image for 
necessary since the driver assumes 
in the task space. Since it is in 


$: 


pped message buffer it 

i s 

not available to the driver. 

SAVRGS 

'•:ro> 

/ 

Save registers, SRGCB destroys 



i 

RO, Rl, Sc R2 

MQV 

#XTL. ADR, R1 


Set buffer size 

MOV 

#F«REHD, RO 


RO points to free memory iisthead 

CALL 

$RQCB 

} 

Allocate new block 

BCC 

IS 


Clear? -it made it 

} Error 

allocating buffer 


MOV 

#SE. RSC, C. SRVS(R5) 

; Resource error 

CLR 

C. IDSB<R5) 

:* 

Clear 1st word of IGSE 

CLR 

C. I0SBr2(R5) 


Clear byte count in ICSB 

RESRGS 

<:ro:> 

j 

Restore registers 

JMP 

ac. SAVE+30. (R5) 


Go to error routine 

MOV 

RO, C. SAVE+6<R5) 

> 

Address of address buffer 

MOV 

Rl, C. SAVE+16. (R5) 

:• Save length for deallocation 

MOV 

C. MADR(R5), Rl 


Rl points to Start of Generic data 

ADD 

#R. GADR,Rl 

} 

Address of extended address 

. REPT 

CXTLADR/2> 

f 

to move 

MOV 

(.Rl)r, <RO) + 

i 

Move the extended address into 

. ENDR 


> 

task image space 

RESRGS 

<RO> 

i 

Restore registers 

JMP 

a<RO)+ 

i 

Goto next entry in table 


CNVBYT: 
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} Switch register count to byte count for R/W register 

ASL C. SAVE+4<R5> ; Shift # words to bytes or data 

JMP S<RO)+ i Go to next entry in table 


BYTCHK; 

} * 

; Compare byte count rec^uested with current byte count for 
; message buffer. 


MOV 

C. MADR(R5>. R1 

/ 

R1 points to Start of Generic data 

MOV 

M. DL£N<R1). R1 

} 

R1 paints to previous returned byte 



} 

count 

SUB 

#R. GDAT, R1 

i 

Actual data bytes 

BL£ 

50^ 

i 

Need more than zero 

CMP 

Rl, #R. GLDT 

/ 

is it bigger than the max i/o 

BL£ 

204 

p 

transaction for this device? 

MOV 

#R. GLDT, R1 

i 

Use the smaller of the two. 

CMP 

Rl,C.SAVE+4(R5) 

i 

Compare to raq,uestad 

BLT 

304 

} 

Need >« 0 

JMP 

a(RO)> 

9 

Go to next table entry 

MOV 

#SE. CNT, C. SRVS<R5) ;• Bad count recues ted. 

JMP 

SAVE+30. (R5) 

9 

Go'to . error routine 


ALCBUF: 

; Allocate dynamic buffer area 


SAVRG4 

<:ro:> 

> Save registers 

MOV 

G4CSYN, R1 


SUB 

#R. GDAT, R1 

; make actual 

CMP 

Rl, #R. KGLDT 

; Compare buffer size with 
allowed for QIu ma.ximum 

3L£ 

104 

Take the smaller of the two 

MOV 

#R. KGLDT, Rl 

} Set buffer size 

MOV 

#F4REHD, RO 

> RO points to free memory iisthead 

CALL 

4RQCB 

Allocate new block 

3CS 

304 

; Set? — it didn't allocate 

MOV 

C. SAVE+2, {R5), 

C. SAVE+12. (R5) ; Save old 
; buffer address 
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30%: 


MOV 

MOV 

MOV 

RESRG« 

JMP 


C. SAVE+18. (R5), C. SAVE+20. (RS) ; Save 


RO>C. SAVE+2<R5) i 
Rl, C. SAVE+18. (R5) 
'•:R0> ; 

a(RO)+ > 


buffer length 
Move in new buffer 
i Set actual length 
Restore registers 
do to next entry 


old 

address 


; Error 
MOV 

RESRGS 

JMP 


allocating buffer 

#SE. RSC, C. SRVS(RS) i 

<:ro> ; 

sc: SAVE+30<R5) i Nested 


Resource error 
Restore registers 
AST level error 


VALBIT: 


10 %: 


Validation 
Device XXC 

MOV 

CMPB 

BOT 


MOV 

JMP 

CMP 

BEG 

CMPB 

BGT 

SUB 

INC 

JMP 


C. MADR(R5)i R2 
#16. . R. GB0F(R2) 
i0% 


10 %: 


20 % 

#8. .. (R2) 

20 % 

#8. i (R2) 

C.SAVE+6(R5) 

S<RO)+ 


nts 

to b yt 

e adjustment of bit 

med 

others 

byte 


R2 p 

oints 

to Start g 

eneric da 

Chec 

k for 

valid bit 

offset 

Less 

than 

okay 


► Generic 

error/ re 

jec t 

f un-c 

tion b 

ecause of 

ad dres s 

Flag 

error 

and retur 


; I 

s this 

a XXC fun 

c tion? 

Yes/ 

1 eave 

as word a 

Iigned 

Po in 

ting to second b 

y te 

Fits 

in fi 

rst byte 


Po in 

t to b 

it within 

byte 

Move 

addr 

up 1 byte 


Go t 

0 next 

entry in 

tab I e 


INIBIT; 


Initial register 
; When exiting/ R2 


setup for bit alignment operations 
= bit offset negated for right shift 


MOV 

MOV 

NEG 

ADD 

MOV - 

MOV 

ADD 


C. MADR(R5)/R3 / R3 points to Start generic data 

R. GBOF<R3)/R2 ; Minus bit offset 

R2 / Shift to the right 

R. GBOF<R3)/C. SAVE+4(R5) ; Add due to bit offset 

C. SAVE+2(R5)/ R4 ; Address of buffer 

#-16. / C. SAVE+2S. <R5) ; Possible shifts plus one 

R.0ADRr30. <R3)»C. SAVE+28. (R5) ; Setup alignment 
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JMP a(RO)+ 


numb er 

Qo to next table entry 



ALQNBT: 


3it alignment for bit uirite operations 
; R2 ® bit offset into word (negated for right shift operation) 


SAVROS 

<R0> 

} Save registers 

i: 

CLR 

R1 

; Clear low order second register 

1; 

nov 

C. MADR(R5), R3 

; R3 points to Beginning of message data 


ADD 

#R. GDAT. R3 

} Beginning of message data 


104; 




MOV 

C. SAVE+a<R5)» 

(R4)+ i Move PC address to buffer 


INC 

C. SAVE+6<RS) 

i Point to next word in PC 

1 

MOV 

(R3>+, RO 

; R1 points to Bit data 

I 

SAVRG4 

<R3> 

; Save pointer to data 


MOV 

C. MADR(R5), R3 

; R3 paints to Beginning of message data 


ASHC 

C. SAVE+2S. <R3) 

/ RO ; Shift double word needed bits 

1 

MOV 

Rl, (R4) 

; Store set bits in out buffer 


MOV 

(R4)+/2(R4) 

/ Set up clear word 2 words away 


MOV 

C. SAVE+6(R5) / (R4)> ; Move next PC address in buffer 


INC 

C. 3AVEr6<R5) 

; Ready for next PC address 


COM 

<R4> 

; Reset mask for bits cleared 


CMP 

C. SAVE-^4(R5) / R 

. GCNT(R3) i Shifting first word 


BLT 

304 

; No/ into bit operation 


We are on fir 

'st word.* save t 

he bits not requesting chan*ge 


SAVRG4 

<R0:;- 

• Save for next shift 


MOV 

#-i, RO 

.: Set mask to all ones 


ASH 

R. GEOF <R3) .* RO 

; Shift bit pointer amount 

1 

COM 

RO 

; Save mask bits set to Is 


2IC 

RO.* (R4) 

f Save low order bits 

i 

RE3RG4 

<R0> 

; Restore for next shift 


304: 

. 


1 

ASHC 

R2. RO 

; Setup for next shift 

I 

MOVE 

(R4)> RO 

; Swap low with high ardar next word 

I 

MOVE 

-3(R4>> (R4) 

; Move high order to next word 


MOVE 

R0>-3<R4) 

i Move low clear to high prev. byta 

1 

ADD 

#2.. R4 

Point to next address 

1' 

SUB 

#16. .• C. '3.AVEr4(R5) .; Decrease number of bits iefb 

1 

RESRG4 

<:r3> 

.: Restore pointer to data 

1 

BGT 

104 

; not done yet 

1 

We are on last word 


1 

; Save bits in 

high order that 

did not request updating 

t 

MOV 

#—1/ RO 

Set up save mask 

i 
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MOV 

ADD 

ASH 

MOV 

SWAB 

SUB 

BICB 

BIOS 

BICB 

BICB 

MOV 

MOV 

MOV 

RESRG« 

UMP 


#16. /R1 

C. SAVE*t-4(R5), R1 
R1 ^ RO 
ROi R1 
R1 

#6i R4 
RO,(R4) 

RO, 1 <R4> 

Rl,4(R4) 

Rl, 5(R4) 

C. SAVE+14. (R5>, C 


C. MADR(R5>, R3 
R. GADR(R3 
CRO 
S<RO)+ 


Number of possible shifts +1 
Subtract number shifted 
Shift mask for low order byte 
Rl for high order 
Save mask for high byte 
Point back to set word 
Save clear bits 
Save set bits 
Save high order set bits 
Save high order clear bits 
SAVE+4(R5) ; Store number of 
bytes to write 

R3 points to Beginning of message 


data 


?, C. SAVS-»-6(R5) i Reset PC address 
; Restore register 
} Go to next entry in table 


ALGNWD: 

; Bit alignment within word for XXC write bit operations 
R2 = bit offset into word (negated for right shift 


ooeration ) 


SAVRG^ <:ro> 

CLR Rl 

MOV C. MADR(R5), R3 

ADD #R.GDAT,R3 

CMP #16. , C. SAVE-^-Ak'RS) ; Test for one word byte 

BGE 10$ i If within one word okay 

MOV #SE. CNT, C. SRVS(R5) ; Move in invalid count 

; to srvc sts 

RESRGS <R0> i Restore registers 

JMP ®C. SAVE+30<R5) ; Error route out 


Save registers 

Clear low order second register 
R3 points to Beginning of message data 
Beginning of message data 


count 


error 


10 $: 


MOV <R3)r,RO 

MOV C. MADR (R5), R3 ; 

ASHC C. SAVE+2S. (R5), RO 
MOV Rl, (R4> 

MOV (R4)+, <R4) } 

COM <R4)+ ; 


Rl points to Bit data 
R3 points to Beginning of me 
;Shift double word needed bi 
Store set bits in out buffer 
Set up clear word 
Reset mask for bits cleared 




We are on 
First and 

MOV 

ASH 

COM 

BIC 


first word, save the bits not requesting change 
only for now 


#-l, RO 

R. GB0F(R3>, RO 
RO 

RO,-(R4) 


i Set mask to all ones 
Shift bit pointer amount 
; Saved mask bits zeroed 
; Save low order bits 
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30 ^: 


We are on last uiord 

Save bits in high order that did not request updating- 


MOV #-l.RO 

ASH C. SAVE+4<R5), RO 

BIC RO,(R4) 

SIC RO,-<R4) 


Set up save mask 
Shift mask 
Save clear bits 
Save set bits 


Force a one uiord entri^ < ACP accepts only one uiord 310) 


MOV #4, C. SAVE+4<R5) 

40«: RE5R0« <R0> 

JMP a<RO)+ 


Store number bytes to write 

Restore register 

Go to next entry in table 


CALCBY; 


; Calculate number of bytes from bits sent down for GIO operation 


MOV 

MOV 

ADD 

ADD 

ASH 

10 ^: 

CMP 

BEG 

ASL 

20 ^: 

CMP 

3NE 

ADD 

BIC 


C. MADR<R5),R3 
R. GBaF(R3).Rl 
C. SAVEH-4<R5). R1 
#7, Rr 
#-3, R1 


R3 points to Beginning of message data 
Bit pointer into byte 
Number of bits working with 
Force a round up to the next byte 
Divide by S 


M. CODECR3); #MG. RED ; Bit read? 

204 ; YeS/ no addr in data 

R1 ; Double/ due to masking space 


C. MODLCRS)/ 
304. 

#1/ R1 
#1/ R1 


#MD. XXC ; Is this XXC function? 
s Go on 

i Inc to next byte 
; Fores even 


304: MOV 

JMP 


Rl/C. SAVE+14. <R5) ; Number of bytes to write 
G(RO)-** ; Go to next table entry 


RSRBYT: 

Place the calculated byte count into GIO parameters 

number of 
sent 

Is entry 


MOV C. SAVErl4. <R5)/C. SAVE+4(R5) 

JMP iS(RO)r 


Calculated 
; parameters 
Go to next tab 
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SETSTS; 

Set up device status operation 



MOV 


CMP 


BNE 


MOV 


MOV 


BR 

104: 

MOV 

204: 

ADO 


JMP 


#10. I C. SAVE'H4(R5) ; 1C bytes expected 
C. MQDL<R5.^» #MD. XXC ; Is this a XXC request 
104 ; Bypass byte count change 

#1S. .. C. SAVE+4(R5) ; IS bytes for XXC 
C. 3AVE+S. (R5). C. SAVE(R5) ; Move in status 

; function 

204 i Need subfunction yet 

C..3AVE<R5),C. SAVE+8. <R5) ; Get address of 

ifunctions 

#2# C. SAVE+0. (R5)i Point to subfunction 
S<R0)+ i Go to next table entry 


STRSTP: 


Set up start 

CLR 
. JMP 


stop operation 

C. SAvE+4(R5) 
S<R0) + 


There is no data to be transferred 
Go to nex,t table entry 


QENQIQ: 


QIC's paraffleters were initially set up in the LCBINI function 
routine parameters are stored in C. SAVE(.l) thru C. SAVE(S) for 
easy retrieval in case of timeouts or block check retries. 


The QIC parameters for the QIC 


MOV 

C. LAB(R5)> R4 


MOV 

L. LUN<R4), R4 

i 

MOV 

R5, R3 

i 

ADD 

#C. SAVE/ R3 

f 

MOV 

#G£iNAST/ R2 / 

Get 

MOV 

RO/ C. SAVE+10. 

(R5) 

ADD 

#2/ C. SAVE-^10. 

/ 

(R5) 


QI04S e(R3)/ R4, > , R5, R2/ <2(R3). 4( 


are 

R4 points to LAB for this device 
R4 points to Logical unit number 
Copy LCB beginning 

R3 points to Beginning of saved data 
address of completion AST 
} Save next entry of function 
br tb 1 

; Point to next entry beyond. . . 

3)/ C. STN(R5). 6(R3), ®S. (R3>. TMOUT> 


MOV C. MADR (R5) .• R3 » R3 points to Beginning of generic data 

MOV 4DSWjC. SRVS(R5> j Generic status message 

BMI 504 ; Take error route if directive 
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SO**; 


JMP 

JMP 


S<RO)+ ; 

«C. SAVE+30. (R5) ; 


error 

Go to next table entry point 
Send error and exit 


3ENAST: 


; Generic service AST reentry point and recovery routing 

ASDIM* i Save registers RS-RO> 

; RS points to LAB of operation# and 
i (sessage buffer pointed to 
} by C, MPNT(R5) and C. ML£N(R5) 
i is remapped and the address of 
; message header is placed in 
; C. MADR<R5) 


MOV #ASTERRi C. SAVE-rSO, (RS) ; Default error routine 

i is noui AST type 

; Determine if there has been a time out or block check 


CMPB 
BEG 
CMPB 
BNE . 

C. lOSB<R5)##IE. TMO ; Test for time out condition 

lOS i Yes# dec count and retry 

• C. lOSB<R5)# #IE. BCC ; Test block che'ek condition 

IS”? / No# determine status and condition 

DEC 

BLE 

C. 7RY(R5) / 

Number of retries 

Done trying - continue 

; Re - 

issue GIO 


MOV 

MOV 

MOV 

ADD 

MOV 

C. LA3(R3)#R4 

L. LUN<R4)#R4 ; 

R5, R3 

#C. SAVE# R3 ; 

#GEIMAST, R2 

R4 points to LAB for this device 

R4 points to Logical unit number 

Copy LCB beginning 

R3 points to Beginning of saved data 


GIQ^S (2<R3># R4# # , R5# R2# <2<R3).. 4(R3># C. STN(R5)# 6(R3)# «S. <R3)# TMCUT> 


MOV 

C. MADR<R5), R3 


R3 points to Beginning of generic 

MOV 

SDSW# C. SRVS(R5) 

> 

Return SDSW sttqt code 

BMI 

20a 


Finished generic request 

MOV 

C, 3AVE+10. <R5).# 

RO 

f 

} Restore pointer to function 
branch table 

JMP 

2(RO)+ 

p 

Go to next function branch entry 
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; DSW error 

j%: 

CLP 

JMP 


R1 

SC. SAVE+30. (R5) 


For other than read functions 
take exit route 


QIOEXM: 


; Determine RSX i/o error then send the generic error code> if 
successful then continue uiith next step in function branch 
; table 


20 «: 


29S: 


30 ^: 


35 «: 


CLR 

C. SRVS<R5) 

i 

Generic error message area 

MOV 

#IOERR.R1 

» 

R1 points to i/o status er-rof table 

MOV 

#IOERCT/R2 


R2 points to Size of error table 

CMPB 

C. I0SB(R5). (R1 

> i 

Determine i/o status 

BEQ 

30% 

i 

go to insert generic function 

ADD 

#2. R1 

i 

Try next entry 

SOB 

R2. 29% 

> 

Do until end of table 

MOV 

#S£, INT, C. SRVS 

(R5 

) i Function error returned 

BR 

35% 

i 


MOVE 

1 (R1 )i R1 

} 

Byte status error 

MOV 

Rl. C. SRVSCRS) 

} 

Insert generic status 

CMP 

R1,SE. sue 

i 

Was it successful? 

BNE 

35% 



JMP 

S(RO)+ 



CLR 

R1 


Error - clear byte ent 

JMP 

ac. SAVE+30. (R5 

) } 

End generic function 


RDMVBT: 


Align bits to send back upstairs for requested read bit 
operation. Send bit string format of only bits request 
; beginning with bit offset into word 


SAVRG^ <CRO> } Save registers 

MOV C. MADR(R5)>R3 ; R3 points to Beginning of message data 

MOVE R. GB0F(R3)i R2 i Bit pointer within word 

NEO R2 i For right shifts 

MOV C. SAVE***4<R5) / C. SAVE+14. (R5) ; Copy bytes read in 

MOV C. SAVE+2(R5)»R3 ; Allocated buffer read into 

MOV C. SAVE+12. (R5), R4; Return buffer 

10 %: 
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MOV 

< R3) R1 


First \iiord in low order register 

MOV 

<R3). RO 


Move into high order register 

ASHC 

R2. RO 


Shift to the right 

MOV 

Rl. (R4) + 


Move low order to message buffer 

SUB 

#2.- C. SAVE+14. 

<R5) 

.• Decrease bgtes left to shift 

BOT 

10^ 


Not done, shift again 

MOV 

#-^C0. RO 

i 

Set up mask 

MOV 

C. MADR<R5)> R3 

> 

R3 points to Beginning of message data 

MOV 

R. 0CNT<R3).R2 


Save bit count 

BIC 

#*^C1S. / R2 

i 

Mask out all but word 

BEG 

20^ 



ASH 

R2. RO 

i 

Shift masked bits 

BIC 

RO. -<R4) 

i 

Save bits not requested 

R£SRG$ 

<B^0> 

i 

Restore registers 

JMP 

3<R0) + 




3ITCMP: 


; Bit 

comparison 

1 for write/verify 

bit operation 


SAVROS 

<R0> 

/ 

Save registers 


MOV 

C. MADR(R5). R3 

i 

R3 points to Beginning of message data 


MOV 

R. GCNT<R3). R2 

/ 

Number ofbits written 


ADD 

#R. GDAT, R3 

/ 

R3 points to Start of input bits 


MOV 

C. 3AVErl2. (R5) 

, R4 

; R4 points* to Bits read in from PC 

LG'S : 

SUB 

. rt 

. 

Decrease number of bits left 


aQE 

20^ 

i 

More bytes to go 

We 

are on the 

last byte to compare 


MOV 

#-l. RO 

; 

Set up mask 


ASH 

R2. RO 

f * 

To the left 


3ICB 

RO. <R3) 

i 

Clear input 


3ICB 

RO.(R4) 

i 

Clear read in 

20 S: 

CMPB 

(R3;.(R4) 

; 

Compare current byte 


BNE 

30« 

> 

Bits not the s-ame? 


TST 

R2 

* 

Done? 


3GT 

i OS 

/ 

No. go to next byte 


RE3R0S 

<:ro> 

f 

Restore register 


JMP 

G<RO)r 

9 

Go to next table entry 

30S: 

MOV 

#S£. VFY. C. SRVS<R5 

) ; Verification error 


JMP 

»2C. SAV£r30, (R5 

) ; 

End of generic function 
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i CMPBUF: 

Routine to 


MOV 

MOV 

ADD 

MOV 

10 «: 

CMPB 

BNE 

SOB 

JMP 


30$: MOV 

MOV 
MOV 
JMP 


c'Ompare buffer written and 


buffer read 


bac k 


C. SAVEr4<R5), R1 
C. MADR<R5)> R3 
#R. ODAT, R3 
C. SAVE+2<R5)i R2 


R1 

points 

to 

Number of 

bytes t 

R3 

points 

to 

Start gen 

eric dat 

Write buff 

er 



R2 

points 

to 

Beg inning 

of read 


(R2)+i (R3) + 
30$ 

Rl, 10$ 
S(RO)-^ 


; Test current byte and inc 
i Error in data 
> Move thru buffer areas 
i Go to next table entry 


#SE. VFY, C. SRVS 
C. MADR<R5), R3 
#SE. VFY, R. GSTS 
«C. SAVE+30. (R5 


(R5) i Verification error 

i R3 points to Start generic 
(R3) i Generic error 
) } End generic function 


data 


DALBUF: 

Deallocate temporary work buffer 



TST 

BEG 

C. SAVE+IS. 
10$ 

(R5) 

SAVRG$ 

MOV 

<zno> Ri> 

#F$REHD,RO 


MOV 

MOV 

CALL 

MOV 

C. SAVE+IS. <R5) 
C. SAVE+2. (R5), 
$RLCB 

C. SAVE+12. <R5) 

MOV 

C. SAVE+20. 

<R5> 

CLR 

RESRG$ 

C. SAVE+20. 
<R 1 p Ror^ 

<R5) 


10 $ ■ 

JMP ®<R0)-»- 


} Get length of dealloc buffer 
; Nothing to deallocate 

.! Save registers 
} Address of free memory 
; listhead 

R1 ; Size of block to be released 
R2 ; Address of block released 
; Release it 

C. SAVE+2. (R5> ; Restore old 
i buffer area 

C. SAVE+18. (R5) ; Restore old 
i buffer length 

; Mark second buffer deallocated 
i Restore registers 


; Go to next entry 


DALXTA: 



Deallocate memory used for storing address buffers within 
task image space. 


compare 

buffer 
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TST 

C. SAVE+16. 

<R5) } 

Was meniory allocated for a 


BEG 

204 

i 

extended address function ? 


SAVRQ4 

<R0. Rl> 

» 

Save registers 


MOV 

#F4REHD, RO 

} 

Address of free memory 


MOV 

C. SAVE+16. 

i 

(R5)i R1 

listhead 

; Size of block to be released 


MOV 

C. SAVEr6. (RS). R2; 

Address of block released 


CALL 

4RLCB 

i 

Release it 


CLR 

C. SAVE+16. 

<R5) J 

Mark it deallocated 


RE5RGS 

<R1,R0> 

i 

Restore registers 

20«: 


JMP 

G<RO)r 

i 

Go to next entry 


CLNUP: 


; Successfully completed requested generic function 
; Set up status returns and registers then call PDDON 

MOV C. MADR(RS)/ R3 ; R3 points to Beginning of gener 

MOV C. LAB<RD}#R4 ; R4 points to Associated LAB 

MOV #SS. sue. C. SRVS(RS) ; Generic status 

MOV C. SAVE+4(R5) / R1 ; Save byte count 

CALL 4PDD0N i Perform cleanup operations 

JMP G(RO)r ; Finish exit AST 

NOFUNC: 



JMOP function 

routine for devices not supporting all generis 

functions 



CLR 

R1 ; 

Zero number of bytes 

MOV 

#S5. sue. C. SRVS<R5) ; Generic success message 

CALL 

aPDDON 


JMP 

G<RO)r ; 

Generic operation doesn't 



for current device 

GEMERR: 



MOV 

#1. RO 


BR 

S4 . 


ASTERR: 



CLR 

RO 



data 


C-70 


Device Inter-face Modules 


£ ; Error; clean up routine. Clean up any allocate buffers Clear any 

data being sent back and either return or exit AST depending 
on which entry point taken 

5$: 

MOV 

ADD 

C.MADR<R5) / R3 ; R3 points to Beginning of generic 

#R.QDAT;R3 ; Point to address of data 

5AVRG$ 

MOV 

<R0> 

#F4REHD,RO 

Deallocate 

primary buffer 

TST 

BEQ 

C. SAVE+IS. (R5) ; Was memory allocated for the 

10$ primary buffer ? 

MOV 

MOV 

CALL 

C. SAVE+13. <R5);R1 :• Size of block to be released 

C. SAVE+2. (R5);R2 ; Address of block released 
$RLCB ; Release it 

Deallocate 

secondary buffer 

10 ^; 

TST 

BEG 

C. SAVE+20. (R5) / Was memory allocated for the 

20$ ; secondary buffer ? 

i MOV 

MOV 

CALL 

C. SAVE+20. (R5);R1 , Size of block to be rel’eased 

C. SAVE+12. (R5>;R2 ; Address of block released 
$RLCB Release it 


Deal 

locate ext 

;ended address buffer 

20$:' 





TST 

C. SAVE+16. (R5) 

Was memory allocated for a 


BEQ 

30$ ; 

PLC3 extended address function ? 

• 

MOV 

C. 3AVE+16. (R5);R1 

.: Size of block to be released 


MOV 

C. SAVE+6. (R5); R2 ; 

Address of block released 


CALL 

$RLCB ; 

Release it 

30$: 





RESR0$ 

<R0> 



CLR 

R1 

Zero byte count 


CALL 

$PDDON 

- so function is bypassed 


TST 

RO 

Determine how we get out of here 


BEG 

50$ 



JMP 

GENE.ND 

Return to caller 

50$: 





JMP 

ASTEX7 

Return from AST 



data 
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QENEND; 

; E-xit at non—comp 1 etion AST lavel 

RESRGdi <ROi Rli R2i R3# R4» R5> i Rastora ragistars 
RETURN i Raturn to collar 


ASTEXT: 

/ Exit intarmadiata AST 

RE5RGS <RO* Rl« R2i R3« R4» RS> » Rastora ragistars 
ASTX«S ; Exit AST 

. DSABL LSB 
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APPENDIX D 


ADDING NEW DEVICE SUPPORT 


D. 1 Overvieui 


The information presented in this Appendix is useful to those 
individuals uiho are adding new device support. 


D. 2 Useful Reading Material 


The following publication -may be useful when planning the 
addition of new device support: 

0 SHOP FLOOR GATEWAY Installation Guide/Re1ease Notes 

o User ' 5 Guide to the Allen~Brad1eu Data Hio h wa u Networ k 
Communication Software <13/NET) 

(1770-343» available from A1len-Bradley; useful if the user 
is writing a DIM for unsupported A11en—Brad 1ey devices^ or 
another utility) 


D. 3 Hardware / Software Environment 


The GATEWAY system is implemented on PDP-11 series processors/ 
each containing a minimum of 512K bytes of memory. A maximum of four 
gateways are supported. The processors are connected to a VAX via a 
DECnet link and to programmable device networks via asynchronous 
serial lines. 

The GATEWAY system uses the RSX-llS operating system. This 
operating system features minimal overhead while providing a real-time 
multitasking.environment. 
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DECnat from 
BASEWAY 


V 


DMR-11 
davica 


POP -11/24 
912 KB nafliorg 


0211 


I I I I I I i r 


DZll 


I I I I I I I I 

I • I • I • I I 


vvvvvvw vwvvwv 


Modbus 1 and/or Data 
Highttfag 2 linas 



Figura 11. BASEWAY Natuiork 





1 Modbus TM is a ragisterad tradamark of Gould Incorporatad>- Modicon 
Division. 

2 Data Highuiag TM is a ragistarad trademark of A11 en-Brad 1 eg 
Corporation. 
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D. 4 SHOP FLOOR GATEWAY Tasks 


APPLICATION 


SHOP FLOOR GATEWAY TASKS 


TSKWCH 
Task 
Watch er 


NETINT 
Network 
Interface 




-—-—+ 


3U3WCH \ 

1 GATEVP 1 1 

1 GENSRV j 

! DIRSRV i 

Device ' 

! Gateway 1 ! 

I Generic 1 

1 Direct • 1 

Set ! 

i Event 1 1 

! Access ! 

! Access 1 

Watc her 1 

Processor 1 ! 

' Server 1 

! Server ! 


! POLSRV 

i 

1 

Dili Device 1 

1 Polling 

1 S3S 

Interface 1 

! Server 


Nodule ! 


Driver 


'I ACP 


Programmab1e Devices 


Figure 12. SHOP FLOOR GATEWAY Tasks 
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D. 5 GATEWAY Initialization 


A Sgsteffl Startup is performed when the GATEWAY system is first 
powered on^ and thereafter whenever a complete GATEWAY restart is 
requested. ' ^nitiallyi DECnet downline loads the GATEWAY system and 
programs. 

After the operating system is initialized and certain tasks that 
perform system and application initialization have been downloaded and 
completed# a copy of the Task Watcher task is downline task->loaded 
from BASEWAY. The Task Watcher task then requests the network 
interface# creates the intertask mailboxes# and starts the other tasks 
running. 

Initialization of the GATEWAY tables is performed after 
everything is in readiness. The GATEWAY Initializer on the 
application traverses the required databases and sends messages 
containing the polling parameters to the GATEWAY Event Processor. 
GATEVP builds the memory’-resident polling tables from these messages 
and enables the Polling Interface. 


D. 5. 1 Network Interface (NETINT) 


The Network Interface task allows tasks to communicate regardless 
of DECnet limitations or functionality. In addition# it performs the 
following actions; 

0 except for certain control messages# routes incoming 
interprocess messages to the proper destination 
transparently# 

o maintains queues for outgoing messages# 

o optimizes message traffic over DECnet#* 

communicates directly with other Network Interface tasks on 
other processors as required. 


0 
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D. 5.2 GATEWAY Event Processor <GATEVP) 

^ ■ 

The GATEWAY Event Processor subsystem is responsible for 
controlling the operation of the GATEWAY system. The GATEVP task 
resides in every GATEWAY sustemi and is controlled and monitored by 
the TSKWCH task. 

On GATEWAY initialization* the GATEWAY Event Processor receives 
configuration messages from BASEWAY which are used t-o set up VDR 
database. This database is used by the Polling Interface to determine 
the polling requirements and status of the system. 

Its activities include: 

0 sending raw PD data to BASEWAY after qualification and 
preprocessing* depending on register definition* 

0 accepting messages from BASEWAY to load PD definitions in 
VDR; 

o returning a status report to BASEWAY on command* 

0 interacting with the Network Interface and various system 
management fuTictions on the SFG; 

5. 2. 1 PD Data Processing - 

The GATEVP task performs PD register qualification and any 
preprocessing of data before the message reaches BASEWAY. This 
includes; 

o analyzing whether a status bit or data changed before sending 
it to BASEWAY. 

0 determining whether to process trigger buffers; 

o converting PD register data from BCD to binary numbers* 


Data to be sent is first formatted into polled data messages.* 
Next* depending on the type of register being processed* one or more 
data packets are packed into the message for transmission. The 
process which GATEVP sends a data message to is part of that data's 
definition (the default.is DATA^PROC). One' data packet is defined for 
each each status or maintenance bit* trigger buffer* or data count 
register. Each polled data message has a header containing the 
equip.ment logical ID and a time~date stamp. Each data packet is 
identified with data identifier code. 
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D. 5. 3 OATEWAY Task Watcher (TSKWCH) 

The Task Watcher task: 

0 monitors the status of each taak in the GATEWAY system^ and 
informs the application when problems occur; 

0 handles system startup and shutdown. 

The Task Watcher task runs continuously on the GATEWAY. 


D. 5. 4 Device Set Watcher <BUSWCH) 


The Device Set Watcher task monitors and controls the 
accessibility of device sets for the GATEWAY.' It is responsible for 
initially determining uihat device sets are currently attached to the 
GATEWAY. It is also responsible for synchronizing the access server 
activity with these events. 


D. 5. 5 Direct Access Server (DIRSRV) 


The Direct Access Server task provides a direct driver interface 
a programmable device^ bypassing the protocol-handling features of 


. . 

i;he PD support Ancillary Control Processes (ACPs). 
task 


.n 


addition.* the 


does not add device—specific protocol to messages sent to 
programmable devices (allowing user application programs on 
3ASEWAY to do protocol for special situations); 

performs simple transactions on the. device networks. 


The 
software 
example.* 
BASEWAY does 


Direct Access Server is useful when a vendor—supp1ied 
program e.xi3ts to do downline loads» upline dumps> etc. For 
in Modbus TM applications the standard Modicon software on 
ail of the protocol and retry processing and uses the 


Direct Access Server to process one Modbus TT1 packet at a time. 
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u. 5. 6 Generic Access Server (GENSRV) 

.vy 

The programmobie device Generic Access Server is responsible for 
Derfcrming any generic i/o to a programmable, device. It performs 
T'ivgister read/uirite functionsi coil read/write> unprotected memory 
access^ etc. ThuSi application programs running on BASEWAY may read 
and uirite to programmable devices uiithout* regard to protocols/ unique 
device architectures/ addressing schemes/ and other such matters. The 
Generic Access Server task: 

0 accesses devices via simple requests such as ''read register/'* 
"uirite COi 1 5/ " etc. ; 

o handles protocol/ retries/ etc./ in conjunction with the 
device support ACPs. 


The request and reply messages have the same general format 
regardless of the make or model of device. 


5.7 rolling Server (PQLSRV) 


The Programmable Device Polling subsystem is implemented by the 
.-■'ILSRV task. It is responsible for systematically "polling" each PD 
d informing the rest of the system whenever polled data changes, 
e Polling Server task is driven by tables which are initially built 
cn the application and .are loaded into tables in the GATEWAY by the 
Event Processor task. Polling is done for each device specified in 
the table/ with a given set or sets of data definitions being, polled 
■iz specified intervals. In general/ data from the scans is sent back 
to BaSEWAY only if a point value changes. 

The POLSRV task is also a highly data-driven program. It scans 
the data structures in the Virtual Data Region/ pausing at specific PD 
polling set blocks to poll selected PD data. Whether a FD is palled 
dopends on a number of flags and status bits in the VDR data 
structures/ and whether polling a PD generates any further processing 
depends on the previous contents of the registers and the data type. 
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D. 9. S Adding a Neui Device to a GATEWAY 


The following steps mag be used as a guide to adding a new device 
to the SHOP FLOOR GATEWAY: 

1. Decide if a terminal driver can be used. If it cannot> you 
must write a device driver and ACP (optional) to communicate 
with the new programmable device. 

2. Edit SFG^ROOT;CSOURCE. DIM3DEVC0D. MAC. and add the new device 
manufacturer and model codes. 

3. Create a new Device Interface Nodule (DIN) for the new device 
(see Appendix C). 

4. Edit SFG^ROOT:CSOURCE. DINIDEVVEC. NAC to include the new DIN. 

5. Relink DIRSRV» GENSRVi and POLSRV to incorporate the new DIN. 

6. Copy DIRSRV. TSK,. GENSRV. TSK, and POLSRV. TSK to SFG^SYSTSN. 

7. Nodify SFG^SYSTEN: SFGVNR. CMD to load the driver and install 
the ACP. 

S. Invoke SFG«SYSTEM: GATEWAY. CON. 


See the SHOP FLOOR GATEWAY Software Installation Guide and 
Release Notes for help with system tailoring. 


D. a Adding A New Device to BASEWAY 


The following steps can. be used to add a new device to BASEWAY: 

1. Update the module BASE^DEVICE^TYPE^DEFS in BSL'$DEFS library 
to reflect the new manufacturer# device# network# etc. 

2. Recompile BSL^ROOT: CSOURCE. LIBRARY3PDAPGNFR. PLI# 

PDAPGNOD. PLI# PDAPTNFR. PLI# PDAPTNOD. PLI# UARBFNFR. PLI# and 
UARBFNOD. PLI and insert the resulting object files in 
BSLSLIBRARY. 

3. If the device will support uploading# downloading# and 

comparing# then create subroutines for each function and add 
references to these subroutines in 

BSLSROOT: CSOURCE. LIBRARY3PDAPDNLDD. PLI# PDAPUPLOD. PLI# and 
PDAPCONP. PLI. 
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I-P the device will not support these functions^ then 
modify PDAPDNLQD* PDAPUPLOD# and PDAPCOMP to return a 
PDAP^.NOTSUPPORTED status condition. 

4. If the device will support start and stop functions/ then 
modify PDAPSTART and PDAPSTOP to send appropriate requests to 
the SHOP FLOOR GATEWAY. If the device will not support these 
functions/ then modify PDAPSTART and PDAPSTOP to return a 
PDAP_$NOTSUPPORTED status condition. 

5. If any device-specific errors need to be parsed/ modify 
PDAPERROR to parse it. 

6. Add commands to PDAPTRAN to translate ASCII addresses to 
"internal addresses" that the GATEWAY DIM recognizes. 

7. Add code to PDAPNXTAD to find the next valid internal address 
for this device. 

S. Modify BSL^ROOT: CSOURCE. UTILITY. EDTBASLIN3EDTDEVDEF. PLI to 
reflect new device parameters and network. Relink EDTBASLIN. 
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APPENDIX E 


GLOSSARY 


The follou/ing terminology is intended to aid the user in 
jnderstanding various concepts and terminology used in the BASEWAY 
sgstem. 


-address - address in a programmafaie device (device—dependent). 


pplication - set of programs performing a single function. An 
'plication may be defined to run on up to 4 VAX processors^ but can 
,ly be active on a single processor. processors*via DECnet. 


ilASEWAY node - VAX./VMS processor 
i-ATEWAY and receives data from the 


compiled address - an internal 
device. 


uihich loads and initializes the 
SHOP FLOOR GATEWAY. 


representation of a programmable 


uata identifier - a unique internal identifier that is assigned to a 
data item at definition time. 


data item - represents a unique piece of data associated with a shop 
floor device. Data items may be gathered automatically from a SHOP 
floor GATEWAY/ or may be updated via a callable subroutine interface. 
Each data item has a value associated with it. 


data na/ne - a unique name assigned by a user to a data item. 
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device — See Programmab1e Device. device set - a collectior of 
programmable devices that are connected to a SHOP FLGOP GATEWAY. Up 
to four device sets may be attached to a single gateway. Although a 
device set can be defined for up to 4 gateways^ it can only be active 
on a single gateway. 


eq.uipment ~ a polling unit/ not necessarily physical equipment. 


gateway (data collector/ SHOP FLOOR GATEWAY/ or SFG) - a PDP-11 
processor dedicated to the task of communicating with shop floor 
devices. Acts as a "gateway" between the shop floor devices and ' an 
application. May be up to 4 per BASEWAY. 


host node - a VAX/VMS processor which loads# initializes# and receives 
data from the SHOP FLOOR GATEWAY. 


interprocess communication - message-passing facilities which allow 
two processes to communicate. A message is created and then the data 
io be sent is stored in it. The message is then sent to the 
destination by calling the SE^4D procedure# specifying a destination 
port. 


interprocess message - a message sent from one process 1 
~hesa messages have a stand.ard header associated with them. 


another. 



line - one of the bhree sets of 3 lines on a single coi.lector. Each 
iet of S lines connects to S A11 sn—Brad 1 ey Data Highway Tid , 3 r'lodicon 
'icdbus TH networks# or terminal support drivers# for bar—code scanner 
■3 •••rVi c es. 


nessage code - a unique message identifier in the range 1—32767. 


nessage port - a value of type PORT represents a systern—maintained 
message queue. PORT values are unique in that they are valid anywhere 
in the network (including in other applications). Thus# transmission 
messages between two processes is completely transparent. Gnce 
written# programs can be distributed and redistributed among the 
network nodes with no changes. 


named messsage ports - names can be given to message ports to 
facilitate communication between jobs. Names exist as systemwide or 
groupwide logical names equating the port name with a port identifier. 


c.— s: 




Glossary 


NAU (netuiork addressable unit) ~ an internal numeric identifier 
'^sociated uiith a particular data stream uiithin a system. Normally^ a 
ocess has a single NAU allocated to it^ but may have more. Up to 
127 permanently assigned NAUs and 127 temporary NAUs are available. 


NAX ~ an internal numeric identifier associated uiith a system. 
Assigned at system definition time. 


network - a series of systems in a DECnet environment. 


node - a processor that is connected to other processors via DECnet. 


polling set each machine may have an unlimited number of polling 
sets/ each characterized by a polling frequency (.1 seconds—30 
minutes)/ a starting register address# and the number of consecutive 
registers to be polled. 


process - a single program running on an application. Equivalent to 
VAX/VMS processes and RSX-llS tasks. 

programmable devices - up to 32 or 64 stations on each Nodficon Modbus 
1 or A11 en-Brad 1 ey Data Highway TM line#- or terminal support driver 
or bar code scanners. 


register - data register or status register. May be bit (or coil)/ 
byte/ word/ longword/ or string. 


shop floor entity - physical or logical entity in the shop floor that 
is referenced by a unique name. Each has a unique number assigned to 
it at definition time. Examples are* machines# conveyors# departments# 
work cells# maintenance cribs# and stations. 


system - an application# device set# or gateway. Referenced by a 
unique name. 
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Data formats 
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Data identifier 

definition of. E—1 

Data item 
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Data name 
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Data types .. 1-16 

atomic .. 1—16 
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string. 1-16 

OATA.PROC. 1-14 

example* of. 1-19 

polled data handling with . . . 1-14 
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see DIMS. C-1 
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Device Set Watcher. D—6 
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DIMS. C-1 
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server interaction with .... C-1 
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Equipment 

definition of . . 

uipment access . . 

i=.vent Processor . . 

see also EVENT^PROC 
EVENT^LOG . 


EVENT PROC 
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B-3 

B-2. D-5 
B-2 
1-13 
1-13 


Functions 


A-1 


QATE.INIT . 

Gateway 

definition of . 

Gateway Loopback . 

Generic Access . 

Generic access . 

service message format . . . . 

Generic Server . 

see also Generic access . . . 

Get Gateway Status . 

Get Network Status for Gateway . 
Get Polled Device Statistics . . 


1-14 
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2-7 

D-7 

1- 4, B-1, C-9, C-i7 
C-17 

B-2 

B-2 

2 - 8 
2-9 
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Hast node 
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Interpracess communication .... E—2 
/ Trfterpracess messages IrS, £-2 

and data formats. 2—4 

between applications . 1—9 

between gateway and application 1—9 

message codes in. 2-3 

NAU. 2-3 

permanent. 2—3 

temporary. 2-3 

NAX. 2-3 

purposecf. 2-1 

structureof . 2—1 

L.ABs. C—1, C—6 

LCBs . C—S 

Line. E-2 

Line Access Block 

see LABs . C-1 

Line Control Block 

see LCBs . C-1 

Log Event. 2-10 


Message code 

definition of. E-2 

Message codes . 2—3 


Message descriptors 
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prototype for 1-17 

scalar. 1-18 

string. 1-19 

Message port 

definition of. £—2 

>?5s sages.1-6 

routing of. 1-9 

Messaging facility .. 1-4 


Named message ports 

definition of , . . . 

NAU 

definition of . . , . 

NAX 

definition of . . . . 

N£T_INTEH . 

Ne tuior k 

definition of . . . 
N^tujcrk Interface . . . 

see also NET^LNTHR . . 

n d e 

BASEWAY . 

definition of . . . . 

Passing arguments . . . 

by address . 

by descriptor 
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